Re: Fix the Friday attendance bug: make the technicalplenary the last IETF session, like it was before

2009-11-10 Thread Stanislav Shalunov
he meeting size creep, but having a declared "normal day" that's actually clearly not normal. -- Stanislav Shalunov BitTorrent Inc shalu...@bittorrent.com personal: http://shlang.com ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf

Re: Fix the Friday attendance bug: make the technical plenary the last IETF session, like it was before

2009-11-10 Thread Stanislav Shalunov
If it's not good enough for the technical plenary, if that's what you're saying, let's not put WGs there. -- Stanislav Shalunov BitTorrent Inc shalu...@bittorrent.com personal: http://shlang.com On Nov 11, 2009, at 12:31 PM, Fred Baker wrote: On Nov 10, 2009, a

Re: Fix the Friday attendance bug: make the technical plenary the last IETF session, like it was before

2009-11-10 Thread Stanislav Shalunov
heduled on Friday as long as we have a Friday. Second, do we have ~19 more WGs that would trade off having the Friday pain for having a consistent meeting day on Friday? -- Stanislav Shalunov BitTorrent Inc shalu...@bittorrent.com personal: http://shlang.com On Nov 11, 2009, at 4:04 AM

Re: Fix the Friday attendance bug: make the technical plenary the last IETF session, like it was before

2009-11-10 Thread Stanislav Shalunov
rest the idea that Friday is a normal day. A poorly attended technical plenary would cost us roughly triple the damage we get from poorly attended WGs on Friday and would thus be recouped within a year.] -- Stas -- Stanislav Shalunov BitTorrent Inc shalu...@bittorrent.com personal: http://

Fix the Friday attendance bug: make the technical plenary the last IETF session, like it was before

2009-11-10 Thread Stanislav Shalunov
2] track-hours = sum_slots num_sessions*duration. This is an imperfect proxy for person-hours, because it does not take into account number of attendees of the sessions. (I don't have data on person-hours by day of the week.) To partially mitigate, I avoided picking Tue

Re: [IAB] Call for Comments: "Peer-to-peer (P2P) Architectures"

2009-10-20 Thread Stanislav Shalunov
can manage your account, are, indeed, P2P systems, despite the fact that they have elements that only provide and don't consume a service. Let me know what you think, -- Stas -- Stanislav Shalunov BitTorrent Inc shalu...@bittorrent.com personal: http://shlang.com On Sep 11, 2009, at 3:08

Re: Call for Comments: "Peer-to-peer (P2P) Architectures"

2009-08-10 Thread Stanislav Shalunov
P2P architecture would be suitable to meet the requirements >   of a given application. > > > > > Please provide your feedback before August 15, 2009. > > For the IAB, > > --Olaf Kolkman >   IAB Chair > ___ > IETF-Ann

Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto)

2008-10-22 Thread Stanislav Shalunov
bles clients to learn from the ALTO service information useful for peer selection." Again, this should go forward. Thanks, -- Stas -- Stanislav Shalunov ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf

Summer of Code: Event notification service for the IETF

2006-04-26 Thread stanislav shalunov
RSS, Atom, Mail, and HTML format. There is a strong preference for the system to be coded in Python. -- Stanislav Shalunov http://www.internet2.edu/~shalunov/ This message is designed to be viewed at an angle of 45 degrees

indication of internet-draft status

2005-03-02 Thread stanislav shalunov
ing the status should the Tools team use in the requirements for the tools it is specifying? -- Stanislav Shalunov http://www.internet2.edu/~shalunov/ This message is designed to be viewed with 0.06479891g of NaCl. ___ Ietf mailing list I

email document delivery service

2005-02-03 Thread stanislav shalunov
specifies the requirements for a document notification service. We'd like to better understand how email document delivery is actually used. -- Stanislav Shalunov http://www.internet2.edu/~shalunov/ This message is designed to be viewed at room temper

Re: Last Call: 'Domain Name System (DNS) Case Insensitivity Clarification' to Proposed Standard

2005-02-03 Thread stanislav shalunov
icant confusion. I also agree that "\027" for ESC is unnecessarily confusing. -- Stanislav Shalunov http://www.internet2.edu/~shalunov/ This message is designed to be viewed in boustrophedon. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: 'Domain Name System (DNS) Case Insensitivity Clarification' to Proposed Standard

2005-02-02 Thread stanislav shalunov
e way "\027" meant for ESC would), but that's just a minor typographic convention. -- Stanislav Shalunov http://www.internet2.edu/~shalunov/ This message is designed to be viewed with 0.06479891g of NaCl. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf

Re: [newtrk] List of Old Standards to be retired

2004-12-16 Thread stanislav shalunov
t2.edu/weekly/longit/protocols93-octets.png -- Stanislav Shalunov http://www.internet2.edu/~shalunov/ This message is designed to be viewed upside down. ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf

Re: Yahoo is not using ESMTP

2004-11-15 Thread stanislav shalunov
as in the plot Fred cites.) Even during weeks when there is an unusually large amount of SMTP traffic because of email worms, we're still talking about 2% of traffic being mail. http://netflow.internet2.edu/weekly/ -- Stanislav Shalunov http://www.internet2.edu/~shalunov/ This m

Re: SMTP compressed protocol...

2003-12-05 Thread stanislav shalunov
On Fri, Dec 05, 2003 at 03:38:20AM -0500, John C Klensin wrote: > From a simple syntax standpoint, one option with an advertised > "prefer/ accept" parameter would do the job, and would be much > preferable architecturally to two options. Yes. > connection-time-limited What's a connection-time

Re: SMTP compressed protocol...

2003-12-05 Thread stanislav shalunov
raffic that is email might prefer compression (at the site administrator's discretion). Then, message SHOULD be compressed if and only if both ESMTP peers support compression and at least one of the peers prefers compression. This way, only sites that need compression would end up using it -- fo

Re: SMTP compressed protocol...

2003-12-04 Thread stanislav shalunov
On Fri, Dec 05, 2003 at 03:29:54PM +1200, Franck Martin wrote: > Why SMTP servers do not negotiate to send an 8bit compressed stream > between themselves. In addition to John Klensin's excellent summary I might notice that one more consideration would be the total amount of network capacity that i

Cable Co's view: NAT is bad because we want to charge per IP

2001-11-27 Thread stanislav shalunov
om of its Techology Analysts. Boy, am I glad I don't have to deal with a cable company! "Cable... Where idiotic business models and complete lack of understanding of networks are combined!" P.S.: Just to be clear, the other problem that the article finds with NAT is that it enables

non-US-ASCII characters in IETF documents

2001-09-25 Thread stanislav shalunov
lRXrD5 Wv0Y64As9fM= =uGkA -END PGP SIGNATURE- -- Stanislav Shalunov http://www.internet2.edu/~shalunov/ Beware of Programmers who carry screwdrivers.-- Leonard Brandwein

Re: filtering of mailing lists and NATs

2001-05-22 Thread stanislav shalunov
y choosen subscribers presumably knows how to follow a link. -- Stanislav Shalunov http://www.internet2.edu/~shalunov/ This message is designed to be viewed at 600 mph.

Re: Restaurant Guide: 50th IETF -- Schneier & Cooper

2001-03-21 Thread stanislav shalunov
There's a stack of these guides on a desk opposite to the registration desk. -- Stanislav Shalunov http://www.internet2.edu/~shalunov/ Sex is the mathematics urge sublimated. -- M. C. Reed.

Re: An alternative to TCP (part 1)

2001-02-06 Thread stanislav shalunov
essage to the address above. I guess I just violated that by quoting you. -- Stanislav Shalunov http://www.internet2.edu/~shalunov/ "Nuclear war would really set back cable [television]." -- Ted Turner

Re: An alternative to TCP (part 1)

2001-02-06 Thread stanislav shalunov
than your typical round-trip time of a hundred or two milliseconds. It seems it could start to be a problem at 100Gbps speeds, but current trend seems to be to increase the number of 10Gbps lamdba channels rather than their bandwidth... -- Stanislav Shalunov http://www.internet2.