RE: Reforming the BOF Process (was Declining the ifare bof for Chicago)
See in-line. Dan > -Original Message- > From: John C Klensin [mailto:[EMAIL PROTECTED] > Sent: Sunday, June 17, 2007 9:13 PM > To: Bernard Aboba; ietf@ietf.org > Subject: Re: Reforming the BOF Process (was Declining the > ifare bof for Chicago) > > > > --On Tuesday, 12 June, 2007 09:52 -0700 Bernard Aboba > <[EMAIL PROTECTED]> wrote: > > >... > > For example, by restricting the function of an initial BOF to a > >determination of interest and a decision to form/not form a study > >group, the opportunities for unfairness and bias can be reduced. > >Once the study group had produced a charter and > documentation of the > >formation criteria, the review of these documents could > proceed with > >more information than is typically available as the result of a > >(potentially delayed) 2nd BOF. Also, the review could > utilize existing > >procedures for ensuring transparency and accountability, such as an > >open review process and documentation of DISCUSS comments. > > Bernard, > > Some specific observations on shifting more toward an IEEE model... > > (1) Unless things have changed since I was last paying > careful attention, the process you describe is used to adding > a new project to an existing technical committee. The > process for creating a new technical committee is somewhat > more elaborate. > The IETF has no layer between the steering group (IESG, TSC > (?)) and the WGs who actually do the technical work. We also > usually try to charter WGs on a short-term, project basis > rather than assigning new projects to existing WGs. Because > of those differences, we need to be careful about analogies > unless we are willing to rethink process models in much more > fundamental ways than tweaking the BOF process. Actually I believe that the IEEE have study groups both at the level of technical committees (Working Groups) which end if successful with new projects within existing Working Groups as well as at the level of the whole IEEE which may end with new Working Groups being formed. Now a IEEE Working Group vary very much in size and scope, but there are a few like IEEE 802.1 (bridging, security QoS) and IEEE 802.11 (wireless LAN) which are comparable in size, scope and number of projects with an IETF area rather than with an IETF WG. > > (2) I don't have statistics, but my impression is that most > technical standards work in the IEEE these days (not just in > 802, but more broadly) starts with a proposal to standardize a > specific industry technology. Those proposals are debated and > refined, but the assumption is that little fundamental > engineering or design work is done in the standardization > process. This also differs from case to case. In some IEEE projects work may start with a given technology on the table, in some other there may be more than one, or just an idea or several ideas about how to solve the problem, and much debate happens until an initial proposal is baselined. I do not believe that overall the distribution of cases is significantly different to what happens in the IETF. > We behave as if the IETF is still doing engineering > design work. Maybe it is time to drop that as an inefficient > and ineffective fantasy, but, again, considering that > involves much broader issues than reforming the BOF process. > > (3) Many of us are concerned about the length of time it > takes to move a well-thought-out idea that has significant > support forward from initial proposal to a functioning > standards development effort. Perhaps we should be > concentrating as much on that question as on the one of how > we cut bad, or inadequately supported, ideas off as cleanly > as possible. I believe that the lack of some agreed criteria of approval for new work is a problem. Maybe this is what you mean by 'how we cut bad'. > Adding a study group creation process and a study group > process to the existing opportunities for delay would not > contribute to speeding things up. Indeed, it would do much > the contrary. > > (4) I, and others, have said this before, but my belief is > that the single most effective change that could be made to > the BOF process would be for the IESG to stop taking its > ability to project the future so seriously. As you and > others have commented, the track record on that isn't good > anyway. Suppose, instead, we were to permit WGs to be set up > on a provisional basis, with intense review after some > reasonable period of time and cancellation if they were not > performing adequately and producing results the community > seemed to care about. This would combine some of the > advantages of IEEE-like study groups with a streamlined > process that focused on the one true measure of whether a WG > could produce useful work: starting it up and seeing if it > produced useful work. What would be the differences between 'study groups' and 'WGs set up on provisional basi
Re: Should I* opinions be afforded a special status? (Re: [saag] Declining the ifare bof for Chicago)
Thanks for your response Thomas. Apologies if I had inadvertently given the impression of mistrust in the current leadership, I* and WG chairs. I have very good working relationships with most if not all of the I* folks I interact with. Sure, there have been differences of opinions, but with communication, the differences were either resolved or we agreed to disagree. I try to communicate rather than hold things in and that may have given the impression you are getting. Also, we seldom debate about all the things that went right. :) In at least one of my emails I tried to balance things out by pointing out the positive. I should have tried harder. With that clarification, I will try and respond to some of your notes below: On 6/14/2007 5:08 PM, Thomas Narten wrote: Your ideas that the "IETF is a meritocracy" and that "I* opinions are afforded special status" are to say the least worry me. If you start from a postion that one cannot trust the I*, or WG chairs, etc. (as a number of your recent postings seem to do), then yes, one can't help to be troubled. however, if your basic starting point is one of distrust, it's hard to imagine rules or process or some other management or oganizational structure that will actually work and also prevent abuse. If there is bad intent, very few rules will prevent bad actions. In most cases, I am simply seeking more transparency and determinism in our operation. One of the things that has come about from the discussions is that perhaps a clear cut list of things to be done post-BoF-session from the AD and/or the IAB would be useful. Now some ADs already do this and others are trying to get there. That is a positive thing. What this might remove is an appearance of arbitrary or biased decision making. The I-D tracker is a great example of this. If indeed there were abuse or improper bias, such processes might help independent evaluation. IMO, you have to have a structure/process/rules that assumes people are generally trying to do the Right Thing. For checks and balances, you then also need appeals procedures and a willingness to speak up and challenge parties when there is evidence of bad decision making. Agreed. I guess I challenge when there is an appearance of bad decision making. I would rather not wait until things get out of hand and then attempt use of the hammer of appeals. That is just my personal preference. In my experience, the vast majority of our leadership do try to do the right thing. And when confronted with having made a bad decision, there is usually a genuine effort to fix things and do the right thing. Agreed, the vast majority are indeed trying to do the right thing and provide the right guidance based on their experiences in the leadership positions. It is also important to point out that some of the positions are extremely time consuming. I appreciate the I*'s and WG chairs' service to the IETF very much. Many in fact go out of their way to reach out and communicate and that is also very much appreciated. How do those, I wonder, fit with what's written in the IETF mission web page http://www.ietf.org/u/ietfchair/ietf-mission.html? Your slides on "Bringing new work to the IETF" presented at the Prague meeting that I have just looked at today also seem to be in contradiction to the IETF mission. Your idea that some people's opinions are afforded more weight than others' is certainly not how the consensus process works. Do smarter people hum louder or get to raise both of their hands? What are you saying? If a respected security expert (one who has reviewed many documents, contributed significantly to WG efforts, etc.) comes to a WG and says "there is a problem here", but 5 WG members stand up and say "I disagree and don't see a problem", do you really expect the security expert's opinion to be given strictly equal weight and to just be overruled since 5 voices are greater than 1? Sure, but the the notions of "respected" and "expert" are fuzzy. I have used that argument myself in the past, but it gets us into trouble because the experts venture into topics where they are not experts at in any sense of that word. Bernard and John allude to some of the related issues. The notion of "expert opinion" is also trouble for another reason. It is a longer story and somewhat indirect, so I won't go into that here. The idea that somehow the ADs and the IAB are above the rest of the contributors is just wrong. They are not above the rest in the sense of having absolute power and having to answer to no one. Anyone is free to (and should) challenge their arguments and decisions when they don't appear to be sound. And clearly they have to be able to defend their positions and give concrete or "actionable" justifications. With that clarification, I don't see us being that far off from each other in our understanding of the operation of the IETF. I was challenging
IANA considerations concerns -- specific cases?
All, The ongoing thread has asked some pretty fundamental questions about how we deal with allocations. Many opinions have been expressed. The general discussion is one thing, but I also wanted to make an offer regarding specific cases where people feel that the current IANA rules for a specific number space are obviously wrong, need room for experimentation, etc. We frequently run into such cases. If you have trouble with a specific number space, I would be happy to be the sponsoring AD for a document that fixes that issue. (Or help you find another AD whose area it belongs, point you to an existing WG that could handle it, or help you find a willing author to write the document, whatever is most suitable for the case at hand.) Jari ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Reforming the BOF Process (was Declining the ifare bof for Chicago)
--On Tuesday, 12 June, 2007 09:52 -0700 Bernard Aboba <[EMAIL PROTECTED]> wrote: >... > For example, by restricting the function of an initial BOF to > a determination of interest and a decision to form/not form a > study group, the opportunities for unfairness and bias can be > reduced. Once the study group had produced a charter and > documentation of the formation criteria, the review of these > documents could proceed with more information than is > typically available as the result of a (potentially delayed) > 2nd BOF. Also, the review could utilize existing procedures > for ensuring transparency and accountability, such as an open > review process and documentation of DISCUSS comments. Bernard, Some specific observations on shifting more toward an IEEE model... (1) Unless things have changed since I was last paying careful attention, the process you describe is used to adding a new project to an existing technical committee. The process for creating a new technical committee is somewhat more elaborate. The IETF has no layer between the steering group (IESG, TSC (?)) and the WGs who actually do the technical work. We also usually try to charter WGs on a short-term, project basis rather than assigning new projects to existing WGs. Because of those differences, we need to be careful about analogies unless we are willing to rethink process models in much more fundamental ways than tweaking the BOF process. (2) I don't have statistics, but my impression is that most technical standards work in the IEEE these days (not just in 802, but more broadly) starts with a proposal to standardize a specific industry technology. Those proposals are debated and refined, but the assumption is that little fundamental engineering or design work is done in the standardization process. We behave as if the IETF is still doing engineering design work. Maybe it is time to drop that as an inefficient and ineffective fantasy, but, again, considering that involves much broader issues than reforming the BOF process. (3) Many of us are concerned about the length of time it takes to move a well-thought-out idea that has significant support forward from initial proposal to a functioning standards development effort. Perhaps we should be concentrating as much on that question as on the one of how we cut bad, or inadequately supported, ideas off as cleanly as possible. Adding a study group creation process and a study group process to the existing opportunities for delay would not contribute to speeding things up. Indeed, it would do much the contrary. (4) I, and others, have said this before, but my belief is that the single most effective change that could be made to the BOF process would be for the IESG to stop taking its ability to project the future so seriously. As you and others have commented, the track record on that isn't good anyway. Suppose, instead, we were to permit WGs to be set up on a provisional basis, with intense review after some reasonable period of time and cancellation if they were not performing adequately and producing results the community seemed to care about. This would combine some of the advantages of IEEE-like study groups with a streamlined process that focused on the one true measure of whether a WG could produce useful work: starting it up and seeing if it produced useful work. Since decisions as to whether to charter a WG are somewhat subjective and the IESG has broad discretion, this is a change the IESG could institute --experimentally or permanently-- on its own initiative without our spending energy on changing the processes. Its success would, however, depend on a change of attitude in the community: today, so much effort goes into the charter process because it has become almost impossible, in practice, to kill off a non-performing WG or to put a tight leach on one that is wandering in the weeds. ADs who try to do so do not win popularity contests, to put it mildly. If the IESG saw clear and broad community support for chartering WGs that were questionable but plausible and then tuning charters or killing non-performing WGs if things didn't work out as originally conceived, I believe we could get a great deal of the nonsense, arbitrariness, and delays out of the early parts of the process. But I don't think that support is there, at least yet. Without it, changes in forms or procedures probably do not produce better results and, if delay is considered an important cost, might produce worse ones. regards, john ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [XCON] Re: tsv-dir review of draft-ietf-xcon-bfcp-connection-04
At Sun, 17 Jun 2007 11:07:10 -0400, Brian Rosen wrote: > > Minor nit on the last part: > When the keys are randomly generated and of sufficient length, > these attacks do not obtain > > "obtain" doesn't work. Either "do not succeed" or "generally do not > succeed" or even "usually fail". Actually, I think obtain is fine (though a bit obscure) here. http://en.wiktionary.org/wiki/obtain 3. (intransitive): To prevail; to succeed. 4. (intransitive): To exist Even though the Pervaise confession had never come to light, no reasonable doubt could obtain; for the act in question [...] was on a par with countless other acts committed by the oligarchs, and, before them, by the capitalists. -- Jack London, The Iron Heel. The more common replacement would be "apply". -Ekr ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [XCON] Re: tsv-dir review of draft-ietf-xcon-bfcp-connection-04
Minor nit on the last part: When the keys are randomly generated and of sufficient length, these attacks do not obtain "obtain" doesn't work. Either "do not succeed" or "generally do not succeed" or even "usually fail". Brian > -Original Message- > From: Gonzalo Camarillo [mailto:[EMAIL PROTECTED] > Sent: Sunday, June 17, 2007 5:52 AM > To: [EMAIL PROTECTED] > Cc: Cullen Jennings; [EMAIL PROTECTED]; ietf@ietf.org; [EMAIL PROTECTED] > Subject: [XCON] Re: tsv-dir review of draft-ietf-xcon-bfcp-connection-04 > > Hi David, > > thanks for your comments. Answers inline: > > [EMAIL PROTECTED] wrote: > > I've reviewed this document as part of the transport area > > directorate's ongoing effort to review key IETF documents. > > These comments were written primarily for the transport > > area directors, but are copied to the document's authors > > for their information and to allow them to address any > > issues raised. > > > > This is a relatively straightforward draft about how a > > client opens a TCP connection to a BFCP server when it > > has the server's transport address information. > > > > Section 3 ventures into the area of IP address selection - > > it references RFC 3484 (which is good) and then goes on to > > make additional comments and recommendations on usage and > > state of deployment of the techniques specified in RFC 3484. > > While there's nothing technically wrong with this text, the > > additional comments and recommendations are not specific > > to BFCP, and may belong in a more generic document. > > Given that such a generic document does not exist, we need to give these > recommendations here. > > > > Section 4 starts with "All BFCP entities implement TLS ..." > > That is correct, as RFC 4582 requires this, but it would be > > better to cite RFC 4582 as part of this statement, e.g., > > "[RFC 4582] requires that all BFCP entities implement TLS ..." > > What about performing the following change? > > OLD: > > All BFCP entities implement TLS [7] and SHOULD use it in all their > connections. > > NEW: > > [RFC 4582] requires that all BFCP entities implement TLS and recommends > that they use it in all their connections. > > > > In the second paragraph of Section 4, I would change > > "can request the use of TLS" to "SHOULD request the use > > of TLS". > > OK, I will fix it. > > > Section 5.1 specifies that SubjectAltName identities in > > certificates are to be preferred to Subject identities. > > Is this specific to BFCP or more general? > > We got that recommendation from our security adviser. I do not know > whether this will be documented in a generic document at some point. > > > The following text appears to be an oversight: > > > >If the client knows the server's IP address, the iPAddress > >subjectAltName must be present in the certificate and must > >exactly match the IP address known to the client. > > > > The client *always* knows the server's IP address (e.g., > > DNS returns it). I think the intended case here is that > > the client contacts the server using the server's IP address > > and as a result does not know the server's hostname. Rephrasing > > in that sort of fashion would also express a preference for > > hostname as certificate identity, which I believe is desirable. > > What about performing the following change?: > > OLD: > If the client knows the server's IP address, the iPAddress > subjectAltName must be present in the certificate and must exactly > match the IP address known to the client. > > NEW: > If the client does not know the server's hostname and contacts the > server directly using the server's IP address, the iPAddress > subjectAltName must be present in the certificate and must exactly > match the IP address known to the client. > > > > Section 6 disturbingly shifts between "password" and > > "pre-shared key" and appears to get a few things wrong in > > the process. To begin with, the statement that "TLS PSK mode > > is subject to offline dictionary attacks." is false when > > the PSK is high-entropy. OTOH, it is correct when the PSK > > is low-entropy (e.g., a password, or derived from a password > > without introduction of additional entropy). The discussion > > in Section 7.2 of RFC 4279 applies, especially the last > > paragraph about PSK generation. The section needs to be > > carefully revised to distinguish between "password" and > > "pre-shared key", especially given the mention of use of > > PBKDF2 to generate the latter from the former. > > what about performing the following change?: > > OLD: > > TLS PSK mode is subject to offline dictionary attacks. In DHE and > RSA modes, an attacker who can mount a single man-in-the-middle > attack on a client/server pair can then mount a dictionary attack on > the password. In modes without DHE or RSA, an attacker who can > record communications between a client/server pair can mount a > d
Re: Role of IANA in approving assignments
Robert Elz wrote: And in this case, this is exactly the point. IANA is the INTERNET Assigned Numbers Authority, not the IETF Assigned Numbers Authority - and the code points it assigns and the registries it maintains are used by the Internet as a whole, not just that part of it that participates in the IETF. In my opinion: No. There's no magic in names. The IANA is a function carried out by a department of ICANN. It has inherited the name from the work done by Jon Postel since the time when the Internet was small enough that all the users knew each other by name. But there is no magic in the name that makes this department have any more credibility than any other group that performs functions. We, as the IETF, whose mission it is to "make the Internet work better", need to look at what the function we want to have performed is, and whether the current entity is the best one to perform the function we want performed. Others have to perform the same evaluation when entrusting their registration functions to this entity. The name is just a name. Harald ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
