RE: Fix the Friday attendance bug: make the technical plenary the last IETF session, like it was before
> -Original Message- > From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On > Behalf Of Andrew G. Malis > Sent: Tuesday, November 10, 2009 9:58 PM > To: Fred Baker > Cc: John C Klensin; ietf@ietf.org > Subject: Re: Fix the Friday attendance bug: make the > technical plenary the last IETF session, like it was before > > The IETF meetings have evolved over time. There are now more > activities on Sunday than there used to be. There used to be an > opening plenary on Monday. We used to have WG sessions in the evening > after dinner. There used to be one long plenary on Wednesday evening, > starting at 7:30 PM. When we split the plenary into two, we initially > flip-flopped the two plenaries between Wednesday and Thursday from one > meeting to the next. We used to have more one-hour meetings than we > have now (or at least it seems that way). > > My point is that nothing is set in stone, and the meetings can and > should evolve over time to meet the changing needs of the IETF. > > Personally, I would like to see more one-hour sessions than we have > now - that would force presentations and discussions to be shorter and > more focused. That would be great. It would allow real BoFs, as well, where we can quickly gauge community interest. But until we reduce the 6 hours spent on the two Plenaries, we're being silly. -d > And only allow one WG session per meeting. As has been > noted elsewhere, work tends to expand to fill the time alloted to it. > Perhaps this will allow us to get back to a model where most people > can plan to fly home on Friday, and Friday will be reserved for > specific activities, such as the RRG and WGs that specifically want > more time and are willing to meet on Friday, so that people can plan > their travel well in advance to be able to take advantage of > discounted fares. > > Cheers, > Andy > > On Wed, Nov 11, 2009 at 12:39 PM, Fred Baker wrote: > > > > On Nov 11, 2009, at 2:43 AM, John C Klensin wrote: > > > >> I'd even like to see the Nomcom ask IESG candidates whether they > >> consider unbounded meeting-length creep acceptable and what they > >> intend to do about it. > > > > To be very honest, the number of things we can do is pretty limited. > > > > The number of meeting slots is a more-or-less-fixed number; > we can change > > the number of them in a few ways, but once we have picked a > number of days > > and rented a set of meeting rooms, this is largely about > deciding how we > > will use a fixed resource. We can talk about having more > one-hour slots and > > less two-hour slots, putting more slots into a day by > staying later into the > > evening, putting more slots into the day by running more of > them in parallel > > (more meeting rooms), or extend the duration of the > meeting. Or, we can tell > > working groups that they can't have as many meetings as > they would like. > > > > I'm not sure I agree that Friday is a "problem"; the > problem is that we have > > N working groups asking for M meetings and N*M needs to be > <= that fixed > > number. Friday is a solution, one that has certain > downsides. Stanislaus > > doesn't like the solution and IMHO has not proposed a > solution that tells us > > how to better manage the demands on the resource. > > ___ > > Ietf mailing list > > Ietf@ietf.org > > https://www.ietf.org/mailman/listinfo/ietf > > > ___ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: If you found today's plenary debate on standards track tedious...
> -Original Message- > From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On > Behalf Of Richard Barnes > Sent: Wednesday, November 11, 2009 4:33 AM > To: Brian E Carpenter > Cc: IETF discussion list > Subject: Re: If you found today's plenary debate on standards > track tedious... > > > From the perspective of the world outside the IETF, this is already > the case. An RFC is an RFC is an RFC... +1. And if the IETF wanted to change that perception, the IETF needs to create a separate document stream -- which I think was the intent of the BCP and FYI document streams. But FYI and BCP aren't separate because the documents also have RFC numbers. -d > --Richard > > > On Nov 11, 2009, at 7:25 PM, Brian E Carpenter wrote: > > > Who would like to adopt this idea: > > > > http://tools.ietf.org/id/draft-loughney-newtrk-one-size-fits- > > all-01.txt > > > >Brian > > > > ___ > > Ietf mailing list > > Ietf@ietf.org > > https://www.ietf.org/mailman/listinfo/ietf > > ___ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF Plenary Discussions
On Nov 16, 2009, at 2:08 PM, Melinda Shore wrote: I can think of a few people who I think have been ranting too long as soon as they step up to the mike. So, I think it's probably a mistake to turn plenaries into a techie version of "The Gong Show" - we shouldn't be making it easier to silence people with unpopular or annoying views. At least putting a time limit on speeches at the mike is basically (but not perfectly) non-discriminatory. Yep, and as I noted, it helps to encourage folks to organize their thoughts and be more concise in their questions or statements for the benefit of the community, AND the I*. -danny ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF Plenary Discussions
On Nov 16, 2009, at 11:56 AM, Brian E Carpenter wrote: I agree that the I* should listen to the community, but then the community should regulate itself. Maybe we need a new tradition - something like a polite hum when someone has been ranting for long enough, and a loud hum when they have been ranting for too long? I can think of a few people who I think have been ranting too long as soon as they step up to the mike. So, I think it's probably a mistake to turn plenaries into a techie version of "The Gong Show" - we shouldn't be making it easier to silence people with unpopular or annoying views. At least putting a time limit on speeches at the mike is basically (but not perfectly) non-discriminatory. Melinda ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF Plenary Discussions
On 2009-11-17 09:12, Bob Hinden wrote: > >> >> >> Reaction to the timers was quite mixed, going all the way from love to >> hate; we never did a survey of the participants afterwards, I think. >> We probably should have. > > I was one of the folks who "hated" it. I view the open mikes as the > time for the community to speak to the leadership (IESG, IAB, and now > the IAOC). IMHO a timer sends the message that the I* does't want to > listen to the community. > > Note, I don't like the long rants either, but in this case the cure is > worse than the disease. I agree that the I* should listen to the community, but then the community should regulate itself. Maybe we need a new tradition - something like a polite hum when someone has been ranting for long enough, and a loud hum when they have been ranting for too long? Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF Plenary Discussions
Reaction to the timers was quite mixed, going all the way from love to hate; we never did a survey of the participants afterwards, I think. We probably should have. I was one of the folks who "hated" it. I view the open mikes as the time for the community to speak to the leadership (IESG, IAB, and now the IAOC). IMHO a timer sends the message that the I* does't want to listen to the community. Note, I don't like the long rants either, but in this case the cure is worse than the disease. Bob ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Gen-ART LC review of draft-dusseault-http-patch-15.txt
--On Sunday, November 15, 2009 14:54 -0800 "Roy T. Fielding"
wrote:
> On Nov 15, 2009, at 12:03 PM, John C Klensin wrote:
>...
>> We should not be adopting a "patch" protocol that lacks both
>> the tools for, or a serious discussion of, transactional
>> integrity.
>
> John, HTTP is not SQL. The transactional integrity is inside
> the resource implementation. The entire transaction consists
> of a single request message and a single response message.
> HTTP is responsible for the communication interface, not the
> implementation of specific resources, and cannot proscribe a
> specific transaction semantic because it is NOT WANTED by
> many resources.
Roy, I certainly agree with the first part of this. HTTP is not
SQL. If it were, I (at least) would be loudly insisting on an
integrity mechanism. However, normal IETF practice includes
being explicit about issues and traps with specifications. So,
while it is plausible to take the position you express above,
that just about requires that the specification explicitly
indicate that verifying transactional integrity is the
responsibility of the calling application. I'm also suggesting
that it should at least point to ways to do that. The
paragraph in Security Considerations (Section 5) that reads:
"A document that is patched might be more likely to be
corrupted than a document that is overridden in
entirety, but that concern can be addressed through the
use of mechanisms such as conditional requests using
ETags and the If-Match request header."
is not, IMO, adequate in that regard, at least absent a
normative reference. It is also the key to the issue as I see
it: while POST can be used to simulate PATCH, the normal and
obvious use of POST is to supply some information to the server
or to replace ("override") an entire document, PATCH would seem
to have, well, patching as its primary purpose.
> For example, a collaborative whiteboard in which many people
> are patching at once, the patches consisting of context diffs
> that are internally capable of distinguishing conflicts, would
> be impossible to implement via standard etag behavior.
Sure. So say that in the document. My problem is _not_ with
the mechanism, it is with what you apparently assume people will
figure out for themselves or learn through oral tradition.
> Standard etag conflict resolution is not required because
> it is not desirable for many applications of PATCH. For
> other applications of PATCH, it is already defined by HTTP
> and does not need to be reiterated here.
We disagree. I believe it does "need to be reiterated here",
either in-line or by an explicit, normative, pointer to the
relevant portion of the HTTP spec.
john
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Re: IETF Plenary Discussions
Olaf Kolkman wrote: During previous technical sessions I mailed an announcement about the technical plenary and in those announcements I've asked something along the lines of: If you consider asking a question during the open-microphone session it would be helpful to send that question to the IAB in advance. In that way we may be able to think about the problem and answer your question effectively. Note that sending in a question is _not_ a requirement for asking one. I believe that submitting questions in advance will help to get concise questions asked (because some thought went into phrasing them) and get pointed answers (because some thought went into answering them). In fact the questions may be shared by the larger group and not just the individual opinions of the folk that are happen to be on stage. Perhaps we should look into http://moderator.appspot.com/ ? FWIW, in the sessions I had asked this questions nobody walked up during the microphone. I just forgot to add the paragraph in this weeks announcement. --Olaf Olaf M. KolkmanNLnet Labs Science Park 140, http://www.nlnetlabs.nl/ 1098 XG Amsterdam ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF Plenary Discussions
Spencer Dawkins wrote: i am remembering that this is correct. i have a faint memory that the timer might have been per topic (so you cut off the followups and moved to the next question), at least once or twice. i have a faint memory of a lot of things. harald? :-) Both experiments were run - at one stage, we ran a 2-minute participation timer and a ~20-minute topic timer - this had the additional twist that we had one mike for raising new topics and 2 mikes for commenting on the current topic. Quite an overengineered scenario, I think; my clearest memory of that session was the guy who stood at the "topic" mike quietly for 20 minutes waiting to say "thank you for all the good stuff we got done". Reaction to the timers was quite mixed, going all the way from love to hate; we never did a survey of the participants afterwards, I think. We probably should have. Harald spencer - Original Message - From: "Tony Hansen" To: "IETF Discussion" Sent: Thursday, November 12, 2009 11:11 AM Subject: Re: IETF Plenary Discussions Didn't Harald put up a timer sometimes during open mike? Tony Hansen Russ Housley wrote: I did not take the comment as disrespectful. A timer might be a very good experiment. Russ At 05:53 AM 11/11/2009, Danny McPherson wrote: Russ, Olaf, et al, I was serious in my recommendation to experiment with limiting question (comment) time at the microphone at plenaries. I believe it'll not only help mere mortals pay more attention, but will also encourage those folks that have questions or comments to be more concise, thereby keeping the audience better engaged. I honestly mean no disrespect and appreciate the wealth of institutional knowledge that's on hand and frequently shared, I just believe that it'd be more effective use of such precious time (and encourage more discussions on this list :-). -danny ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Background on IETF 79 Decision
On Mon, Nov 09, 2009 at 04:40:20PM +0900, Bob Hinden wrote a message of 84 lines which said: > In response to concerns that the discussion of some IETF topics may > violate the law, the IAOC has been assured by the Host that a normal > IETF meeting can be legally held in China and that no pre-screening > of material or monitoring of session content is required or will be > done. Which does not mean no problem will occur: http://www.mis-asia.com/news/articles/igf-2009-event-rattled-by-un-security-office ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: FYI: SPDY
> -Original Message- > From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On > Behalf Of Phillip Hallam-Baker > Sent: Thursday, November 12, 2009 4:47 PM > To: Mark Nottingham > Cc: ietf@ietf.org > Subject: Re: FYI: SPDY > > Sounds good. But making HTTP faster is somewhat less of a concern to > me than making it easier to make it more robust. And the big problem > in all these schemes has been how to detect that there is a speedier > option and WHICH ONE TO CHOOSE. > > Anyone can make a 'negotiation' mechanism that allows you to choose > between existing HTTP and their scheme du jour. Thats not really > architecture in my view, you have to solve for the rather more general > case without having code of this type > > if (token1 = frobble) >protocol = speedy > elseif (token2 = magicQ) >protocol= m12 > elseif (token3 = ei3ir) >protocol = jeie > else >protocol = http > > This approach works only so long as you have code to support. It tends > to assume we are surfing not web servicing. > > > We have this SRV header that has some really useful mechanism to help > provide reliable service. As a side benefit it also allows us to avoid > the need to always use port 80. That could be an important factor in > conserving IPv4 addresses > > We need a general purpose signalling mechanism that is DNS based and > applicable to any protocol negotiation of this sort. draft-yourtchenko-tran-announce-dns-00 is a start in that space. -d > > On Thu, Nov 12, 2009 at 4:24 PM, Mark Nottingham > wrote: > > Chromium has been experimenting with speeding up HTTP using > a new protocol, > > SPDY. > > > > See: > > http://blog.chromium.org/2009/11/2x-faster-web.html > > http://dev.chromium.org/spdy/spdy-whitepaper > > > > My (personal) take: > > http://www.mnot.net/blog/2009/11/13/flip > > > > Interesting times. > > > > Cheers, > > > > -- > > Mark Nottingham http://www.mnot.net/ > > > > ___ > > Ietf mailing list > > Ietf@ietf.org > > https://www.ietf.org/mailman/listinfo/ietf > > > > > > -- > -- > New Website: http://hallambaker.com/ > View Quantum of Stupid podcasts, Tuesday and Thursday each week, > http://quantumofstupid.com/ > ___ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Logging the source port?
Stephane Bortzmeyer writes: On Fri, Nov 13, 2009 at 10:49:36AM +0100, Arnt Gulbrandsen wrote a message of 11 lines which said: Therefore, I think it's safer to say that it's the NAT operator's responsibility to log enough. Umpteen million web sites will continue to use apache's common log format, so the NAT operator has to log what's needed to work with that format anyway. How could it be possible? The only way I see for the NAT operator to be able to say that the customer X went to www.priv.no at 2241 UTC is to log not only the source-address/source-port mapping but also the *destinations*, which create obvious privacy issues (and would make the log *much* larger). Yes. But do you see a way to avoid that, except by unrealistic declarations such as "all apache installations that use the common log format must be changed"? It's not just apache either, all other (web and other) servers that don't log source port. (Btw, there is no www.priv.no, and these days I don't think you can get anything else under .priv.no either. The dozen-odd people who have .priv.no domains are allowed to keep them, that's all.) Arnt ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Apply Now to Join the ICANN Board, the Councils of GNSO and ccNSO, and the ALAC
Dear all, With my hat as IETF liaison to the ICANN NomCom on. ICANN's Nominating Committee (Nom Com) invites Statements of Interest and candidate recommendations from the Internet community for key leadership positions to fulfill ICANN's technical and policy coordination role. FOr details, see: http://icann.org/en/announcements/announcement-13nov09-en.htm Of course, you can also contact me offline with suggested candidates or any other concerns that you may have. Henk -- -- Henk Uijterwaal Email: henk.uijterwaal(at)ripe.net RIPE Network Coordination Centre http://www.xs4all.nl/~henku P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The NetherlandsThe NetherlandsMobile: +31.6.55861746 -- Nobody ever went broke underestimating the taste of the American public. H.L.Mencken ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
