I've recent had to write a program to interface with a SIP lync server and
in doing so have had to code to several rfcs. After reading and dealing
with implementation of the various rfcs I have read I have come up with
what I consider "A modest proposal" to fix some of the problems
Why not treat vacation insults like persistent delivery problems?
In other words, automatically unsubscribe the perpetrators.
Everyone makes mistakes now and then, but anyone not competent enough
to pick half reasonable software has no business bothering the IETF.
Let 'em use http://www.ietf.org/
Here's an experiment:
- Create a read-only list, "[EMAIL PROTECTED]"
- People send email to [EMAIL PROTECTED] as usual
- If the from: address is a subscriber to [EMAIL PROTECTED],
majordomo sends it to the members of [EMAIL PROTECTED] and
[EMAIL PROTECTED]
On 1/21/13 7:57 PM, William Jordan wrote:
> Whoever thought it was a good idea to
> allow multiple ways of doing the same exact thing would hopefully be
> deterred by actually writing code to do it.
I think there's general agreement that options are not a good thing and
a pretty decent understan
On Jan 22, 2013, at 08:05, Melinda Shore wrote:
> why you're specifically requesting implementations in C
I think his argument is that the spec author should be punished for each piece
of fluff in the spec.
A sentiment that I can relate to.
Having to write C code probably does qualify as the a
On 1/21/13 10:20 PM, Carsten Bormann wrote:
> Having to write C code probably does qualify as the appropriate
> punishment :-)
I guess that depends on your background ...
> And too bad we can't have the IESG implement it while
> reviewing it.
There we go. That would cut down on the "I'll suppo
On Mon, 21 Jan 2013, Melinda Shore wrote:
> > And too bad we can't have the IESG implement it while
> > reviewing it.
>
> There we go. That would cut down on the "I'll support your
> awful idea if you support my awful idea" horse trading.
No, it just means that I have to implement my awful i
Hi Melinda,
On Jan 22, 2013, at 9:05 AM, Melinda Shore wrote:
> there's general agreement that options are not a good thing and
> a pretty decent understanding of the issues around complexity, but
> there's many a slip, etc.
It may seem to be very easy to agree with you on that point. However, t
On 1/21/13 11:34 PM, Hannes Tschofenig wrote:
> It may seem to be very easy to agree with you on that point. However,
> the story isn't that simple as it first seems to be.
Complex problems often have complex solutions. I think a lot of
people look at sendmail, for example, and go "GAH!" without
the various rfcs I have read I have come up
with
> what I consider "A modest proposal" to fix some of the problems I've
seen
> with implementing a rfc. I think anyone who writes a rfc should have
to
> provide a working ANSI/C or GNU/C implementation of the rfc in
question.
ng with implementation of the various rfcs I have read I have
come up with what I consider "A modest proposal" to fix some of the
problems I've seen with implementing a rfc. I think anyone who writes
a rfc should have to provide a working ANSI/C or GNU/C implementation
of the rfc i
In response to Melinda's first reply, the reason I specifically requested
an implementation in C is because I think its the language that a developer
is the least likely to hang himself with. I've seen plenty of examples of
bad code and I think c gives the least opportunity for a developer to make
Another reason I believe a code implementation of a rfc would be good is
understanding. For me, it is sometimes easier to read an example of code
than to try to read through a rfc description of it.
Bill
William Jordan wrote:
> comma where random whitespaces are allowed. Additionally, I can't
> understand why each line is terminated with , why use two
> characters when one will do.
It is called NETASCII, and is the norm for text-based protocols.
It is a canonical end-of-line representation.
>
us rfcs I have read I have come up with
> what I consider "A modest proposal" to fix some of the problems I've seen
> with implementing a rfc. I think anyone who writes a rfc should have to
> provide a working ANSI/C or GNU/C implementation of the rfc in question.
> Specific
Do none of you know what the phrase "a modest proposal" refers to?
Try googling it.
Janet
ietf-boun...@ietf.org wrote on 01/21/2013 11:57:22 PM:
> From: William Jordan
> To: ietf@ietf.org
> Date: 01/22/2013 12:01 AM
> Subject: A modest proposal
> Sent by: ietf-b
On 1/22/13 8:29 AM, Janet P Gunn wrote:
Do none of you know what the phrase "a modest proposal" refers to?
We should kill and eat more internet drafts before they reach one year
of age.
Try googling it.
Janet
ietf-boun...@ietf.org wrote on 01/21/2013 11:57:22 PM:
> From: W
- Original Message -
From: "Janet P Gunn"
To: "William Jordan"
Cc: ;
Sent: Tuesday, January 22, 2013 4:29 PM
Subject: Re: A modest proposal
> Do none of you know what the phrase "a modest proposal" refers to?
>
> Try googling it.
Or else look t
>Do none of you know what the phrase "a modest proposal" refers to?
No, but I'm sure that this will be a Great Leap Forward.
On Mon, Jan 21, 2013 at 10:57 PM, William Jordan wrote:
> Whoever thought it was a good idea to allow multiple ways of doing the same
> exact thing would hopefully be deterred by actually writing code to do it.
> I think a suitable punishment for those people would be to write each way of
> writi
On 1/22/13 12:34 AM, Hannes Tschofenig wrote:
Another example from a different area: Why do we need so many
transition technologies for the migration from IPv4 to IPv6? Wouldn't
it be less complex to just have one transition mechanism?
You mean no transition mechanisms...
On Tue, Jan 22, 2013 at 4:11 AM, William Jordan wrote:
> Continuing my discussion about how badly SIP is designed, I'm gonna talk
> about the via line. First of all each via line can be expressed as via: OR
> v: OR you can have multiple via entries on the same line separated by a
> comma where r
On 1/22/13 7:16 PM, Dean Willis wrote:
> Microsoft-OS text editors. Seriously. People wanted to be able to
> write correct SIP messages using text editors, and there were more
> Microsoft users than Linux users on the list.
Oh, c'mon. MS products and MacOS at the time used CRLF for newlines
gene
>> Additionally, I can't understand why each line is terminated with
>> , why use two characters when one will do.
>
>Microsoft-OS text editors. Seriously.
My, what a bunch of parvenus. SIP got it from SMTP, SMTP got it from
Telnet. Back in the 1960s we all used because on a
mechanical model 33
On 23/01/2013 04:14, joel jaeggli wrote:
> On 1/22/13 12:34 AM, Hannes Tschofenig wrote:
>> Another example from a different area: Why do we need so many
>> transition technologies for the migration from IPv4 to IPv6? Wouldn't
>> it be less complex to just have one transition mechanism?
>
> You me
Hi Brian, Hi Joel,
the point of my mail was not to start a discussion about the examples I
provided but to note that the suggested "let's reduce complexity by reducing
options" is not as easy as it sounds in practice.
In the context of the document Stephen wrote and the proposal that was made
On 1/23/13 1:27 AM, Hannes Tschofenig wrote:
Hi Brian, Hi Joel,
the point of my mail was not to start a discussion about the examples I provided but to
note that the suggested "let's reduce complexity by reducing options" is not as
easy as it sounds in practice.
The prototypical human enterpri
John Levine wrote:
>
> My, what a bunch of parvenus. SIP got it from SMTP, SMTP got it from
> Telnet. Back in the 1960s we all used because on a
> mechanical model 33 or 35 Teletype, CR really returned the carriage,
> LF really advanced the platen, and you needed both. I first ran into
> CR/LF
> "Tony" == Tony Finch writes:
>> My, what a bunch of parvenus. SIP got it from SMTP, SMTP got it from
>> Telnet. Back in the 1960s we all used because on a
>> mechanical model 33 or 35 Teletype, CR really returned the carriage,
>> LF really advanced the platen, and you nee
A great deal of complexity comes from the fact that standards are
rarely created in a vacuum.
In this case, RFC 3261 SIP had to be upward-compatible from RFC 2543
SIP. And the early design of RFC 2543 SIP was influenced (I am told)
by the idea that SIP messages should be able to go through HTTP
p
Hi All,
Within the IETF, it has become common to use the term a "A Modest Proposal..."
as a title for actual proposals for process change within the IETF. This
causes some cultural dissonance for me, personally, and I want to make sure
that people are aware of the origin of this
Well, Margaret, thank you for the information (I am serious, not ironical).
I (and, I guess, many other IETFers) was not aware about this "historical"
usage of "A Modest proposal..." Although I did not make any proposal so far,
I would have used it out of modesty. You know, to
On Mon, Aug 1, 2011 at 12:45 PM, Margaret Wasserman wrote:
>
> Hi All,
>
> Within the IETF, it has become common to use the term a "A Modest
> Proposal..." as a title for actual proposals for process change within the
> IETF. This causes some cultural dissonance for
12:45 PM, Margaret Wasserman wrote:
>
> Hi All,
>
> Within the IETF, it has become common to use the term a "A Modest
> Proposal..." as a title for actual proposals for process change within the
> IETF. This causes some cultural dissonance for me, personally, and
On Mon, Aug 1, 2011 at 10:08 AM, Hadriel Kaplan wrote:
>
> 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
On Aug 1, 2011, at 3:57 PM, Mark Atwood wrote:
> On Mon, Aug 1, 2011 at 10:08 AM, Hadriel Kaplan
> wrote:
>>
>> 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
Not to mention the strange grammatical "usage" that you hear in
Britain:
"I am stood in front of the office."
"We were sat on the runway for 20 minutes"
(Something you say about chess pieces I suppose...)
or:
"The Bank of England have announced an increase in interest rates"
No wonder us fo
On Aug 1, 2011, at 12:57 PM, Mark Atwood wrote:
> On Mon, Aug 1, 2011 at 10:08 AM, Hadriel Kaplan
> wrote:
>>
>> 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
On 8/1/2011 10:08 AM, Hadriel Kaplan wrote:
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
meetin
Vernon Schryver wrote:
> Why not treat vacation insults like persistent delivery problems?
> In other words, automatically unsubscribe the perpetrators.
Mmm, it probably can't be done automatically, since the mailing list doesn't get the
vacation messages (that I know
of--it doesn't happen with
> > Why not treat vacation insults like persistent delivery problems?
> > In other words, automatically unsubscribe the perpetrators.
>
> How about because the vacation message came to you, the poster, and
> not to list administration? You've got a third-party trust issue right
> there.
Once upon
> Why not treat vacation insults like persistent delivery problems?
go right ahead, you have my blessing to do this for your lists. :)
OTOH enforcing this policy right now on the IETF list would probably
do more harm than good. we can hardly expect the vacation bouncers
to "do the right thing"
> From: Harald Tveit Alvestrand
> Date: Friday, November 05, 2004 1:20 AM
> I'm stepping down as IETF chair in March, and I am not a candidate
> for reappointment.
Harald:
I too would like to congratulate you on your successes, and suggest you have
the opportunity to be the last
On Jan 22, 2013, at 11:45 PM, Melinda Shore wrote:
> On 1/22/13 7:16 PM, Dean Willis wrote:
>> Microsoft-OS text editors. Seriously. People wanted to be able to
>> write correct SIP messages using text editors, and there were more
>> Microsoft users than Linux users on the list.
>
> Oh, c'mon.
Melinda Shore wrote:
>
> Oh, c'mon. MS products and MacOS at the time used CRLF for newlines
> generally, not just in Word.
Classic Mac OS used bare CR for newlines, as did a number of 8 bit micros.
Tony.
--
f.anthony.n.finchhttp://dotat.at/
Forties, Cromarty: East, veering southeast, 4 or
--On Wednesday, January 23, 2013 13:45 -0500 Warren Kumari
wrote:
>...
> Yup, and Unix users have the ability to choose line endings:
> Emacs -
> M-x set-buffer-file-coding-system RET undecided-dos
>...
Not exactly. Depending on the particular version/
implementation, most version of Emacs (w
g'day,
"J. Noel Chiappa" wrote:
...
> Which is precisely why I say that the solution to spam is to charge for
> email. It avoids the whole question of defining what is and is not spam.
>
> More specifically, change the email protocol so that when email arrives from
> an entity which is not on the
--On Friday, 05 November, 2004 18:15 -0500 Noel Chiappa
<[EMAIL PROTECTED]> wrote:
> I too would like to congratulate you on your successes, and
> suggest you have the opportunity to be the last chair to
> preside over active work related to version 6 of the IP
> protocol suite. With the passage
At Fri, 05 Nov 2004 18:33:00 -0500, John C. Klensin wrote:
>
> Oh, my! The potential for a plenary food fight that has nothing
> to do with administrative reorganizations. How very encouraging
> and refreshing. ;-)
The quality of the ballistic grub might be higher than usual at any
rate, sinc
Noel and Tony,
thanks for offering such wonderful foils for a technical discussion!
I'm going to do my best to rile the feathers of both of you, by appearing
to take a strong stand, but actually remaining solidly perched on the fence
between your positions, and manage to rile some so-far unruffle
Dear Harald,
This the first time I agree with everything in an IETF mail. Thank you to
be candid enough to have writen this.
May I just suggest one tunning: "Investigate" rather than "Create the
mobile Internet"? To preserve the possibility that there is not such a
thing as a "mobile", or a "mu
Harald,
While I agree with most of your analysis, I think there is a
different view of address space exhaustion that might be more
helpful and that there are several things the IETF can do to
impede the spread of IPv6. The other side of the "why bother
deploying it" argument is "ok, we've decide
On Sat, Nov 06, 2004 at 12:36:08PM -0500, John C Klensin wrote:
> Even if we ignore the address space issues entirely, we will
> slide smoothly from "NATs in IPv4" to "NATs in IPv6" or, more
> likely, "ever more clever NATs and NAT technologies in IPv4"
> unless we are successful in nailing down
On Sat, 6 Nov 2004, Juergen Schoenwaelder wrote:
> On Sat, Nov 06, 2004 at 12:36:08PM -0500, John C Klensin wrote:
>
> > Even if we ignore the address space issues entirely, we will
> > slide smoothly from "NATs in IPv4" to "NATs in IPv6" or, more
> > likely, "ever more clever NATs and NAT technol
Juergen Schoenwaelder wrote:
On Sat, Nov 06, 2004 at 12:36:08PM -0500, John C Klensin wrote:
Even if we ignore the address space issues entirely, we will
slide smoothly from "NATs in IPv4" to "NATs in IPv6" or, more
likely, "ever more clever NATs and NAT technologies in IPv4"
unless we are succe
On Sat, 06 Nov 2004 09:53:00 +0100, Harald Tveit Alvestrand wrote:
> So the death of IPv4 isn't going to happen with a bang. More like
> a protracted series of whimpers
One of the great dangers of having a history of success is the way it
blinds us to new ways to fail.
In the case of IP address
Dave Crocker wrote:
On Sat, 06 Nov 2004 09:53:00 +0100, Harald Tveit Alvestrand wrote:
So the death of IPv4 isn't going to happen with a bang. More like
a protracted series of whimpers
One of the great dangers of having a history of success is the way it
blinds us to new ways to fail.
In the case
> Dave Crocker wrote:
> By way of noting one possible scanario that builds on today's
> reality and leads down a path that never adopts IPv6,
As of today this _is_ the scenario. IPv6 is not even a buzzword anymore.
> I'll ask: What if users turned all leaf networks into private
> address space, s
Dave Crocker wrote:
> On Sat, 06 Nov 2004 09:53:00 +0100, Harald Tveit Alvestrand wrote:
> > So the death of IPv4 isn't going to happen with a bang. More like
> > a protracted series of whimpers
>
> One of the great dangers of having a history of success is the way it
> blinds us to new ways to
On 11/6/2004 3:53 AM, Harald Tveit Alvestrand wrote:
> In IPv6, I see our job as standardizers to make sure the thing we have
> defined is well-defined enough to let it work, and then get the hell
> out of the way.
Pardon me for saying so, but I think that represents the canonical problem
with v
It seems to me that a lot of what causes working group lists to
melt down is simply the volume of traffic -- usually with plenty
of off-topic banter, or exchanges of dubious value, with the resulting
conjestive collapse of our wetware buffering. On good days, the
drop algorithm may be more sophist
--On Wednesday, January 23, 2013 06:15 + John Levine
wrote:
>>> Additionally, I can't understand why each line is terminated
>>> with , why use two characters when one will do.
>>
>> Microsoft-OS text editors. Seriously.
>
> My, what a bunch of parvenus. SIP got it from SMTP, SMTP got
>
Peter,
[I like Peter even more after he's had a beer]
> Peter Deutsch wrote:
> You probably know this already, but for those who don't, Brad
> Templeton proposed this scheme a while ago, based upon am
> micropayments model and called it "estamps". See:
> http://www.templetons.com/brad/spam/estamp
n
> Subject: "too many notes" -- a modest proposal
>
>
> It seems to me that a lot of what causes working group lists to
> melt down is simply the volume of traffic -- usually with plenty
> of off-topic banter, or exchanges of dubious value, with
> the resulting
> c
draconian rules like this.
Steve Silverman
Andy
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of
Michael Thomas
Sent: Wednesday, January 25, 2006 3:26 PM
To: IETF Discussion
Subject: "too many notes" -- a modest proposal
It seems to m
On 01/25/2006 16:12, Steve Silverman wrote:
> It seems to me that limiting users to 3 messages / day (perhaps with a
> maximum number of bytes) would be a
> minimal impact on free speech but would limit the damage done by
> overly productive transmitters. This could be limited to users who
> are n
We had a discussion on this back in May 2003, and I created a mailing list
for it called "ietf-moderation" - you can subscribe to the list by
http://eikenes.alvestrand.no/mailman/listinfo/ietf-moderation, or the usual
-request spiel.
Total traffic seems to have been 3 messages in May and 9 mes
On Jan 25, 2006, at 2:08 PM, Harald Tveit Alvestrand wrote:
We had a discussion on this back in May 2003, and I created a
mailing list for it called "ietf-moderation" - you can subscribe to
the list by http://eikenes.alvestrand.no/mailman/listinfo/ietf-
moderation, or the usual -request spi
Michael Thomas writes:
> Perhaps we should take a lesson from TCP and set a receive window
> on IETF mailing lists in the face of conjestion. The sender is thus
> obligated to keep the transmission within the window, and as a side
> effect to consider the quality of the, um, quantity. Just this si
Steve Silverman writes:
> It seems to me that limiting users to 3 messages / day (perhaps with
> a maximum number of bytes) would be a minimal impact on free speech
> but would limit the damage done by overly productive transmitters.
> This could be limited to users who are nominated to a "limit"
Andy Bierman writes:
> I do not share your regulatory zeal.
> As a WG Chair and WG participant, I have enough rules to follow already.
> The last thing I want to do is count messages and bytes, and enforce
> draconian rules like this.
But counting messages and bytes happens to be something that c
Anthony G. Atkielski wrote:
Andy Bierman writes:
I do not share your regulatory zeal.
As a WG Chair and WG participant, I have enough rules to follow already.
The last thing I want to do is count messages and bytes, and enforce
draconian rules like this.
But counting messages and byt
Douglas Otis wrote:
> I suspect that at the moment, I am the guilty party in consuming
> bandwidth on the DKIM list. With the aggressive schedule, the
> immediate desire was to get issues listed, corrected, and in a form
> found acceptable.
Without going into all the reasons why here, I asked Do
Eliot Lear wrote:
Douglas Otis wrote:
I suspect that at the moment, I am the guilty party in consuming
bandwidth on the DKIM list. With the aggressive schedule, the
immediate desire was to get issues listed, corrected, and in a form
found acceptable.
Without going into all the reasons why
Andy Bierman writes:
> I think you missed my point.
> I should have said "enforce or abide by draconian rules".
> Automating the process is even worse.
> Then stupid scripts disrupt WG activity on a regular basis.
> Inappropriate mailing list use should be dealt with by the
> WG Chair(s) in a more
Brian E Carpenter writes:
> Exactly. If a WG group is discussing a dozen separate issues in parallel,
> an active participant can easily send several dozen *constructive*
> messages in a day. Our problem with disruptive messages can't be solved
> by counting bytes.
Set a rolling monthly quota, th
Anthony G. Atkielski wrote:
Andy Bierman writes:
I think you missed my point.
I should have said "enforce or abide by draconian rules".
Automating the process is even worse.
Then stupid scripts disrupt WG activity on a regular basis.
Inappropriate mailing list use should be dealt with by th
>Set a rolling monthly quota, then. Nobody constantly sends a long
>stream of consistently productive messages.
We've certainly been made aware of that.
R's,
John
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
> From: "Anthony G. Atkielski" <[EMAIL PROTECTED]>
> Nobody constantly sends a long stream of consistently productive
> messages.
The irony in you, of all people, making this statement is a little stunning -
to the point that one really does start to wonder exactly what could be
behin
Anthony,
...
-->
--> Set a rolling monthly quota, then. Nobody constantly sends a long
--> stream of consistently productive messages.
-->
-->
This is simply not true. All one needs to do is publish a
crucial document relevant to the working groups charter,
and important to understanding th
Andy Bierman writes:
> If we did this, our mailing lists would be bombarded with SPAM
> from non-subscribers.
Then accept e-mail only from subscribers.
> There is an appeals process (of that we are too painfully aware)
> that can be used for people who are told by a WG Chair that
> they are usin
Noel Chiappa writes:
> In that case, there's no harm in the rest of us deciding we don't need the
> dubious "assistance" of few of the most troublesome, and least productive, is
> there?
Actually there is, because there's very little correlation between
being "troublesome" on a mailing list and b
Gray, Eric writes:
> This is simply not true. All one needs to do is publish a
> crucial document relevant to the working groups charter,
> and important to understanding the rest of the work, and
> one will be inundated with questions.
Then maybe message traffic is not a reliable indicator of
On Thu, Jan 26, 2006 at 05:16:59PM +0100, Anthony G. Atkielski wrote:
> Brian E Carpenter writes:
>
> > Exactly. If a WG group is discussing a dozen separate issues in parallel,
> > an active participant can easily send several dozen *constructive*
> > messages in a day. Our problem with disruptiv
Theodore Ts'o writes:
> As a gentle suggestion from one of the Sargeant-At-Arms. If
> you were to keep track of how many messages you have been posting
> compared to others, I think you would find that you are one of the
> more prolific posters on this thread.
And if you were to look at the tota
Brian E Carpenter wrote:
Eliot Lear wrote:
Douglas Otis wrote:
I suspect that at the moment, I am the guilty party in consuming
bandwidth on the DKIM list. With the aggressive schedule, the
immediate desire was to get issues listed, corrected, and in a form
found acceptable.
Without go
Wednesday, January 23, 2013 2:56 PM
Subject: CRLF (was: Re: A modest proposal)
>
>
> --On Wednesday, January 23, 2013 06:15 + John Levine
> wrote:
>
>>>> Additionally, I can't understand why each line is terminated
>>>> with , why use two charac
IIR, Multics from several years earlier. I'd have to dig
through old manuals to remember what CTSS did, but that system
(and the IBM Model 1050 and 2741 devices often used as terminals
with it) were somewhat pre-ASCII (and long before ECMA-48/ ANSI
X3.64 and the VT100 and friends) and, IIR, sen
On Wed, 23 Jan 2013, John Day wrote:
> >
> > IIR, Multics from several years earlier. I'd have to dig
> > through old manuals to remember what CTSS did, but that system
> > (and the IBM Model 1050 and 2741 devices often used as terminals
> > with it) were somewhat pre-ASCII (and long before EC
> From: John Day
>
> Multics was based on EBCDIC which had a New Line (NL) character but
> no CR or LF. The ARPANET went with the ASCII standard. But I never
> forgave the ANSI committee for taking left arrow out of the character
> set (as a replacement operator).
Which suggests that the re
Then what am I mis-remembering? ;-) Was it that Multics didn't use
CRLF and only NL? I remember this as quite a point of discussion
when we were defining Telnet and FTP.
On Wed, 23 Jan 2013, John Day wrote:
>
> IIR, Multics from several years earlier. I'd have to dig
> through old manu
--On Wednesday, January 23, 2013 18:05 -0500 John Day
wrote:
> Then what am I mis-remembering? ;-) Was it that Multics
> didn't use CRLF and only NL? I remember this as quite a point
> of discussion when we were defining Telnet and FTP.
>
>> On Wed, 23 Jan 2013, John Day wrote:
>>
>>> >
>
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 ef
Harald Tveit Alvestrand wrote:
But on mobility, I think we blew it.
I don't know if I agree with this -- most users that I
know are pretty mobile and certainly wireless. So I think
we do have some kind of a "Mobile Internet" already and
there's obviously more to come.
I do not want to comment on th
I don't think I have seen a proposal like this before. I really like it, as
there are a bunch of post-IETF stuff, some of which starts in the afternoon and
thus conflicts with the IETF. This fixes that problem, enables us to have the
same amount of meeting time, and potentially lets people get
+1 to that as well ..an excellent proposal.
-Original Message-
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Eric
Burger
Sent: Sunday, July 31, 2011 11:48 AM
To: Hadriel Kaplan
Cc: IETF-Discussion list
Subject: Re: A modest proposal for Friday meeting schedule
I'd actually vote for NO meetings on Fridays. %90 of attendees fly home
on Friday if at all possible, especially since most of us have flown in on
Sunday. Unless you are local to the meeting, it is a major hassle leaving
after the meetings on Friday, especially if you are international
Thomas Nadeau wrote:
> On Jul 31, 2011, at 11:48 AM, Eric Burger wrote:
>> On Jul 31, 2011, at 11:40 AM, Hadriel Kaplan wrote:
>>
>>> Something like this:
>>> 8:30-11:00 Session I
>>> 11:15-12:15 Session II
>>> 12:30-13:30 Session III
>>
>> I really like it, as there are a bunch of post-IETF stu
: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On
> Behalf Of Hadriel Kaplan
> Sent: Sunday, July 31, 2011 5:40 PM
> To: IETF-Discussion list
> Subject: A modest proposal for Friday meeting schedule
>
> Howdy,
> First I'd like to thank the organizers for IETF-81
On Aug 1, 2011, at 9:39 AM, John Leslie wrote:
> Thomas Nadeau wrote:
>> On Jul 31, 2011, at 11:48 AM, Eric Burger wrote:
>>> On Jul 31, 2011, at 11:40 AM, Hadriel Kaplan wrote:
>>>
Something like this:
8:30-11:00 Session I
11:15-12:15 Session II
12:30-13:30 Session III
>>>
1 - 100 of 216 matches
Mail list logo
