Re: Purpose of IESG Review
Fred Baker (fred) f...@cisco.com wrote: Also, in my opinion, IESG review that raises a certain number of issues should not result in the document sitting in the IESG's queue for a few months while the authors go back and forth with the AD or the GEN-ART reviewer pounding the document into someone's idea of shape without working group involvement. I personally would prefer that simple matters get sorted out between the ADs and the author, but complex changes or additional content requested by the AD should result in the document being sent back to the working group. This is pretty much the call of Working Group Chairs, so perhaps you should ask WGCs what they intend to do -- I don't think an IETF-wide policy would work well here. Note also that when this is done, it seems to reinforce the attitude that We should humor the IESG! (Even so, I personally prefer to hear about such changes. ;^) -- John Leslie j...@jlc.net
Re: Purpose of IESG Review
Seeing randomly selected drafts as a Gen-ART reviewer, I can say that serious defects quite often survive WG review and sometimes survive IETF Last Call review, so the final review by the IESG does serve a purpose. IMHO, if the IESG members sticks to their own criteria at http://www.ietf.org/iesg/statement/discuss-criteria.html, i.e. do not DISCUSS a document for spurious reasons, they are doing just fine. If they don't stick to those criteria, complaint is justified. Of course this will always be a matter of judgment. Regards Brian On 11/04/2013 18:54, Joe Touch wrote: Hi, all, As an author who has had (and has) multiple documents in IESG review, I've noticed an increasing trend of this step to go beyond (IMO) its documented and original intent (BCP 9, currently RFC 2026): The IESG shall determine whether or not a specification submitted to it according to section 6.1.1 satisfies the applicable criteria for the recommended action (see sections 4.1 and 4.2), and shall in addition determine whether or not the technical quality and clarity of the specification is consistent with that expected for the maturity level to which the specification is recommended. Although I appreciate that IESG members are often overloaded, and the IESG Review step is often the first time many see these documents, I believe they should be expected to more clearly differentiate their IESG Review (based on the above criteria) - and its accompanying Position ballot, with their personal review. My concern is that by conflating their IESG position with their personal review, the document process is inappropriately delayed and that documents are modified to appease a small community that does not justify its position as representative. How do others feel about this? Joe
Re: IETF Diversity Question on Berlin Registration?
Ray Expert as the IETF (and its allied organisations) is in Internet Engineering, I doubt if many of those skills transfer into Social Engineering, which is the field in which I think this question lies. Lacking such expertise, into how to frame a question in order to get the answer which is wanted, how to interpret the results of a self-selecting survey, complying with the legislation relating to the handling of personal information in the countries involved, I think that the IETF should stay out of this. Tom Petch - Original Message - From: Ray Pelletier rpellet...@isoc.org To: Ray Pelletier rpellet...@isoc.org Cc: Discussion IETF ietf@ietf.org Sent: Thursday, April 11, 2013 4:17 PM Subject: Re: IETF Diversity Question on Berlin Registration? And please direct your comments to i...@ietf.org Thanks Ray On Apr 11, 2013, at 11:11 AM, Ray Pelletier wrote: All The IETF is concerned about diversity. As good engineers, we would like to attempt to measure diversity while working on addressing and increasing it. To that end, we are considering adding some possibly sensitive questions to the registration process, for example, gender. Of course, they need not be answered and would be clearly labeled as optional. The IAOC would like to hear from the community on this proposal. It plans to make a decision on its 18 April call in order to make the changes in time for the Berlin registration and will consider all input received by 17 April. Thanks for your feedback. Ray IAD
Re: Purpose of IESG Review
Reply to below message The subject SHOULD be: Evaluating Review Process Performance I prefer the Subject is: Evaluating WG input, the WG review process, and the WG output, NOT IESG review. Hi Joe, My comments mostly is on your message, but I comment also on I-Ds or RFCs related to IETF (including joky RFCs). I don't think it is write to evaluate the review of an IESG as long as when we created the I-D and adopted it into IETF SYSTEM, it is already agreeing on the methods of process that I-D is going through. So the problem is to evaluate three things not one: 1) the input, 2) the process review, 3) the output. We may make different input methods that go to another body than IESG, but if you decided to make I-D under IETF current procedure, it will have to go to IESG. I think the IESG are doing an excellent job, but it is best them to evaluate their performance not the community. Or it is better to find a body that evaluates the IESG performance not on this list. I consider your input on the list as a complain about the process, so I ask you to notice that your input has an error that needs evaluation befor going to process evaluation. You may evaluate output, but I remind you to evaluate input of WGs and inputs of individuals. I think the BIG problem of delay in I-Ds or RFC, is the cause of the WG not the IESG, if you do an excellent WG processes you will get quick results at IESG. AB + Hi, all, As an author who has had (and has) multiple documents in IESG review, I've noticed an increasing trend of this step to go beyond (IMO) its documented and original intent (BCP 9, currently RFC 2026): The IESG shall determine whether or not a specification submitted to it according to section 6.1.1 satisfies the applicable criteria for the recommended action (see sections 4.1 and 4.2), and shall in addition determine whether or not the technical quality and clarity of the specification is consistent with that expected for the maturity level to which the specification is recommended. Although I appreciate that IESG members are often overloaded, and the IESG Review step is often the first time many see these documents, I believe they should be expected to more clearly differentiate their IESG Review (based on the above criteria) - and its accompanying Position ballot, with their personal review. My concern is that by conflating their IESG position with their personal review, the document process is inappropriately delayed and that documents are modified to appease a small community that does not justify its position as representative. How do others feel about this? Joe
Re: Purpose of IESG Review
On 4/12/2013 12:13 AM, Brian E Carpenter wrote: Seeing randomly selected drafts as a Gen-ART reviewer, I can say that serious defects quite often survive WG review and sometimes survive IETF Last Call review, so the final review by the IESG does serve a purpose. Brian, Of course it serves a purpose. The lack of perfection in the specifications that reach the IESG has always been the justification for the current review model. But what is tiring about this line of justification is its continuing failure to balance the analysis by looking at the costs and problems that come with it. Does it provide regular and sufficient benefit to justify its considerable costs? First, it is a phenomenally expensive step, with a very damaging organizational cost: the time and effort burden put on ADs makes the pool of available ADs tiny, including dramatically reducing the range of companies that can afford to donate senior (strategic) staff to it. Along with this is the general issue that has triggered Joe's query: the tendency of ADs to inject spontaneous, late-stage personal engineering preferences, which might have been reasonable to add to the original working group discussion but realistically have no place in a final review. It's not that the preferences are necessarily inappropriate, it's that they typically are not essential to the success of the spec. But in terms of the specific logic you've used, the presumption of the it catches errors sometimes language is that the final output that is the result is somehow perfect. Of course, that's a silly assumption. But as soon as one acknowledges this, we are left with a model that must class this as merely one more review in an imperfect sequence, with the likelihood that an every new review will find more problems. Or we are left with the view that pragmatics dictate accepting imperfections because each step of the quality assurance model -- of which this is a part -- really does need a strict cost/benefit analysis. This needs to be done in terms of trade-offs, rather than an isolated approach that counts the detection of an occasional problem as somehow an inherent and controlling good. An essential component to such a trade-off based model is recognizing that the ultimate quality assurance step always has been, and remains, the market. No amount of IETF q/a guarantees success. We have lots of failures and we won't ever get to zero. If the IESG review step really is essential, then we should show a consistent pattern of its finding /essential/ errors that would have caused failure in the field. But if we can find that -- which I believe we cannot -- we have deeper problems, of course, because that sort of shit needs to be found mch, much sooner. At base, the IESG review seeks to compensate for seriously inadequate quality control during the development process... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: Purpose of IESG Review
On Apr 12, 2013, at 12:13 AM, Brian E Carpenter brian.e.carpen...@gmail.com wrote: Seeing randomly selected drafts as a Gen-ART reviewer, I can say that serious defects quite often survive WG review and sometimes survive IETF Last Call review, so the final review by the IESG does serve a purpose. I'm not saying it doesn't serve a purpose. I'm saying that I know of drafts that have been nearly rewritten during such back-and-forth, so what popped out was largely unrelated to what went in. In such cases, I think the document should have been returned to the working group with comments, not worked on privately.
Re: Purpose of IESG Review
On 12/04/2013 14:17, Fred Baker (fred) wrote: On Apr 12, 2013, at 12:13 AM, Brian E Carpenter brian.e.carpen...@gmail.com wrote: Seeing randomly selected drafts as a Gen-ART reviewer, I can say that serious defects quite often survive WG review and sometimes survive IETF Last Call review, so the final review by the IESG does serve a purpose. I'm not saying it doesn't serve a purpose. I'm saying that I know of drafts that have been nearly rewritten during such back-and-forth, so what popped out was largely unrelated to what went in. In such cases, I think the document should have been returned to the working group with comments, not worked on privately. I agree. That should be standard operating procedure. Brian
Re: IETF Diversity Question on Berlin Registration?
On 4/12/2013 12:49 AM, SM wrote: At 13:46 11-04-2013, Spencer Dawkins wrote: If the IAB means members, the number for females, as far as I know(*), is 2/15, or 13 percent. If it means voting members, the number for females is 1/13, or just under 8 percent. If I use the 13% I can say that the IAB is more diverse than the IAOC. Some organizations use political arithmetic to look good. Hi, SM, I was just checking the math. I couldn't possibly say what good means, and I'm interested in better understanding what diverse means, to this, ummm, at least somewhat diverse community ... Spencer p.s. And I wasn't trying to be snarky about the math. I blew the percentages in the first draft of my response, so I know it happens to the best of us :-)
Re: draft-housley-rfc2050bis-01
On 4/8/13 13:45 , John Curran wrote: On Apr 8, 2013, at 9:06 AM, David Farmer far...@umn.edu wrote: 3. Regarding Public WHOIS in section 4; The constituencies and stakeholders for Public WHOIS are much broader than just the technical community, a number of constituencies in civil society have legitimate interests in Public WHOIS. I guess the main point I'm trying to make is that Public WHOIS is more than just a technical issue, and section 4 seems to scope it as solely a technical issue. It's definitely a bigger issue, but it does not seem appropriate in an IETF document to assert points about all aspects of the issue, but instead better to just note the _technical considerations_ of the topic that are needed to keep the Internet running. I don't think you need to refocus section 4 from Technical Considerations I think simply recognizing that there are more than just technical considerations, especially for Public WHOIS, something like the following should be sufficient; 2) ...have included consideration of the technical and operational requirements, as well as requirements of other stakeholders, for supporting WHOIS services... This text would be the authors asserting that these requirements (those of other stakeholders of Whois) have been considered, and yet there are wide range of non-technical aspects to Whois that quite probably have not been fully considered; e.g. issues similar to those in various ongoing discussions of DNS Whois at ICANN this week... The section is about the _technical considerations_ that have been considered in establishment of the Internet Numbers Registry System, and to change the text as you suggest would significantly expand its scope into areas not currently addressed in the text and not typical of other IETF documents, i.e. problematic. You are probably right, but the first paragraph of section 4 says; As a result of the system of technical standards and guidelines established by the IETF as well as historical and operational constraints, there have been technical considerations regarding the services provided by the Internet Numbers Registry System as it evolved. These technical considerations have included: Specifically where it says as well as historical and operational constraints seems to open the door for what I'm talking about. The way it is written, the historical and seem to stand apart from, separate from, or in addition too, the technical standards and guidelines of the IETF. Historical constraints is rather broad and could easily include non-technical considerations. Which the issues of broader society and Public WHOIS are certainly some of the historical non-technical considerations. So I'd suggest that paragraph should get some work, to better represent the intent you have stated for this section. I suggest the following text, based on my interpretation of what you are saying. I feel it better constrains the discussion to the technical domain. In particular changing historical and operational constraints to something like historic operational practices. As a result of the system of technical standards and guidelines established by the IETF, as well as historic operational practices of the Internet community, there are technical considerations regarding the services provided by the Internet Numbers Registry System, these included: Thanks. -- David Farmer Email: far...@umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952
Re: Purpose of IESG Review
Brian E Carpenter wrote: Seeing randomly selected drafts as a Gen-ART reviewer, I can say that serious defects quite often survive WG review and sometimes survive IETF Last Call review, so the final review by the IESG does serve a purpose. I'm currently seeing a document with some serious defects in IETF Last Call (rfc2560bis) and an apparent desire to have it Rubberstamped by the IESG (recycling at Proposed Standard). While that seems procedurally permitted for the IESG to do such rubberstamping (aka waive) for a proposed standard (rfc2026, last paragraph on page 12): http://tools.ietf.org/html/rfc2026#page-12 A Proposed Standard should have no known technical omissions with respect to the requirements placed upon it. However, the IESG may waive this requirement in order to allow a specification to advance to the Proposed Standard state when it is considered to be useful and necessary (and timely) even with known technical omissions. one should really consider the consequences of such a decision, especially for -bis and -ter documents. The original draft (and now full) standard requires that such defects are removed _before_ the document is advanced. So when waiving known defects/omissions (in particular obvious and formally provable ones), this means that there will have to be a ter document produced where this defects are fixed and this document be recycled at Proposed one more time before the standard can progress on the maturity level. It turns out that for a non-negligible amount of the defects there is a constituency that want the defect to be retained rather than fixed, and they expect the IESG to waive defects on -bis, -ter etc. documents whenever it was previously accepted for Proposed with that defect. IMHO, if the IESG members sticks to their own criteria at http://www.ietf.org/iesg/statement/discuss-criteria.html, i.e. do not DISCUSS a document for spurious reasons, they are doing just fine. If they don't stick to those criteria, complaint is justified. Of course this will always be a matter of judgment. Regards Brian On 11/04/2013 18:54, Joe Touch wrote: My concern is that by conflating their IESG position with their personal review, the document process is inappropriately delayed and that documents are modified to appease a small community that does not justify its position as representative. What do you want to see the IESG do instead? Simply Rubberstamp WG consensus? That would turn the whole IESG diversity discussion into an absurd waste of time... -Martin
Re: IETF Diversity Question on Berlin Registration?
Dear Ray, Outcomes, good or bad, are often influenced by groups sharing a common interest. Important questions should attempt to measure whether these interests reflect those of the larger Internet communities. No gender, sexual orientation, ethic, religious, or political background should be excluded, but attempting to ascertain the breath and distribution of interests based on questions used to measure some possible selection bias based on distributions of aspects unrelated to the endeavors of the IETF seems unlikely to improve outcomes. When faced with some distraction from endeavors at hand, a friend of mine would exclaim squirrel! Regards, Douglas Otis On Apr 11, 2013, at 8:11 AM, Ray Pelletier rpellet...@isoc.org wrote: All The IETF is concerned about diversity. As good engineers, we would like to attempt to measure diversity while working on addressing and increasing it. To that end, we are considering adding some possibly sensitive questions to the registration process, for example, gender. Of course, they need not be answered and would be clearly labeled as optional. The IAOC would like to hear from the community on this proposal. It plans to make a decision on its 18 April call in order to make the changes in time for the Berlin registration and will consider all input received by 17 April. Thanks for your feedback. Ray IAD
Re: Purpose of IESG Review
I have no interest in or knowledge of the technical details, but there is a pretty complicated DISCUSS against this draft, which doesn't look like rubber-stamping to me: https://datatracker.ietf.org/doc/draft-ietf-pkix-rfc2560bis/ballot/ I assume you've already let the IESG know about the defects you're concerned about. Brian On 12/04/2013 16:26, Martin Rex wrote: Brian E Carpenter wrote: Seeing randomly selected drafts as a Gen-ART reviewer, I can say that serious defects quite often survive WG review and sometimes survive IETF Last Call review, so the final review by the IESG does serve a purpose. I'm currently seeing a document with some serious defects in IETF Last Call (rfc2560bis) and an apparent desire to have it Rubberstamped by the IESG (recycling at Proposed Standard). While that seems procedurally permitted for the IESG to do such rubberstamping (aka waive) for a proposed standard (rfc2026, last paragraph on page 12): http://tools.ietf.org/html/rfc2026#page-12 A Proposed Standard should have no known technical omissions with respect to the requirements placed upon it. However, the IESG may waive this requirement in order to allow a specification to advance to the Proposed Standard state when it is considered to be useful and necessary (and timely) even with known technical omissions. one should really consider the consequences of such a decision, especially for -bis and -ter documents. The original draft (and now full) standard requires that such defects are removed _before_ the document is advanced. So when waiving known defects/omissions (in particular obvious and formally provable ones), this means that there will have to be a ter document produced where this defects are fixed and this document be recycled at Proposed one more time before the standard can progress on the maturity level. It turns out that for a non-negligible amount of the defects there is a constituency that want the defect to be retained rather than fixed, and they expect the IESG to waive defects on -bis, -ter etc. documents whenever it was previously accepted for Proposed with that defect. IMHO, if the IESG members sticks to their own criteria at http://www.ietf.org/iesg/statement/discuss-criteria.html, i.e. do not DISCUSS a document for spurious reasons, they are doing just fine. If they don't stick to those criteria, complaint is justified. Of course this will always be a matter of judgment. Regards Brian On 11/04/2013 18:54, Joe Touch wrote: My concern is that by conflating their IESG position with their personal review, the document process is inappropriately delayed and that documents are modified to appease a small community that does not justify its position as representative. What do you want to see the IESG do instead? Simply Rubberstamp WG consensus? That would turn the whole IESG diversity discussion into an absurd waste of time... -Martin
Re: Purpose of IESG Review
On Apr 12, 2013, at 11:26 AM, Martin Rex m...@sap.com wrote: I'm currently seeing a document with some serious defects in IETF Last Call (rfc2560bis) and an apparent desire to have it Rubberstamped by the IESG (recycling at Proposed Standard). FWIW, I raised the same question during IESG review. It didn't seem like a serious defect to me, but it did seem like a strange design choice. I ultimately withdrew my objection after we walked through the problem. If we were doing a clean slate design, fixing the problem as you proposed would be a net win. Given that there are substantial existing deployments, it doesn't look like a net win to me. I think this is really a matter of judgment, not a matter of fact, so while I sympathize that it didn't come out your way, I don't agree with you that the wrong thing happened.
Re: Purpose of IESG Review
Brian E Carpenter wrote: I have no interest in or knowledge of the technical details, but there is a pretty complicated DISCUSS against this draft, which doesn't look like rubber-stamping to me: https://datatracker.ietf.org/doc/draft-ietf-pkix-rfc2560bis/ballot/ I assume you've already let the IESG know about the defects you're concerned about. The concern I originally raised durint LC is primarily a defect of rfc5019 that rfc2560bis does not properly deal with, and is in theory fairly trivial to fix. A much more concerning defect has just recently been uncovered: http://www.ietf.org/mail-archive/web/pkix/current/msg32635.html the complete absence of requirements to allow OCSP response caching (and OCSP response cache updating), which is going to become important for the two work items that are currently active in TLS: - a TLS extension for multiple OCSP response stapling - a TLS caching extension and I strongly believe that PKIX needs to fix that defect/omission and clarify the OCSP response caching semantics in rfc2560bis (and document requirements for thisUpdate), or this will result in unexpected and undesirable behaviour (aka interop problems). I have no implementation experience with OCSP, so a number of problems will not be directly apparent to me. But I'm really wondering why noone who has implemented OCSP response caching so far (and I believe there are implementations) has ever brought up this issue against rfc2560 so far. This is close to impossible to miss _for_an_implementor_. -Martin
Re: IETF Diversity Question on Berlin Registration?
On Thu, Apr 11, 2013 at 04:40:57PM -0800, Melinda Shore wrote: My own feeling is that if we were to find that the numbers supported the notion that there's bias present in the system we probably couldn't do anything about it without tearing the organization apart, so, we live with bias, and trying to identify whether or not there's bias in the nomcom process would be something along the general lines of opening the gates of hell and we'd probably be better off not knowing for sure. I still think that the IETF community at large has no intentional diversity bias, so the process of discussing and analyzing diversity in the context of leadership is to help better describe diversity induced job qualifications as well as uncovering any potential unconscious bias to help overcoming it. But I digress. It seems to me that it might be more useful to identify what it is you're trying to find out, first, and in this case I'm really not sure why Ray asked that particular question. Right. Being nomcom, i am of course interested to see what answers we can get to help improve analyzing our situation, so whether or not we can create good analysis vs. divesity fators, I think the questions i proposed just by themselves would give a good insight about awareness in the community about the role of leadership, and maybe give us some more insight into the possible pool. Cheers Toerless
Re: IETF Diversity Question on Berlin Registration?
On 4/12/2013 10:12 AM, Toerless Eckert wrote: I still think that the IETF community at large has no intentional diversity bias, so the process of discussing and analyzing diversity in the context of leadership is to help better describe diversity induced job qualifications as well as uncovering any potential unconscious bias to help overcoming it. I think it's unintentional, as well, but I'm not sure that's *much* of an improvement over malicious bias. It certainly makes it far, far, far more difficult to address. As I said I think that looking at the pool of nominees who've accepted their nominations and comparing it to the pool of people selected would provide one very rough measure of bias (explicit or otherwise) in one stage of the process. Melinda
Re: [pkix] Last Call: draft-ietf-pkix-rfc2560bis-15.txt (X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP) to Proposed Standard
On Apr 10, 2013, at 3:02 AM, Stefan Santesson ste...@aaa-sec.com wrote: Nothing has changed in this regard. The good response is pretty clear that it by default provides information that the cert is not on a black-list (is not know to be revoked). However, it is also made clear that extensions may be used to expand this default information about the status. This is how it always have been, and still is in RFC 256bis. So a non-issued cert may be good. The revoked response simply means that the certificate is revoked. Combined with the new extension, it MAY also be used for non-issued certs. So a non-issued cert may be revoked. It's really as simple as that. I would have thought that what was simple was to say a non-issued cert was unknown, since it's neither known-good, nor known-revoked. Is there any collection of extensions which will allow an RP to know, for sure, what value will be returned for a never-issued cert? It is only the discussion on this list that is confusing and that has managed turn something really simple into a complicated debate. What *I* find confusing is the apparent degree of belief that it is possible to improve 2560 and simultaneously to maintain backward compatibility. That should only be possible if there are some previously-ignored extensions which alter the semantics of the information --- effectively creating a version 2 protocol. I don't find the claim that nothing has changed helpful. What I would find helpful, and what I think some people really would like, is for OCSP to be able to provide white-list information in addition to the previous black-list information. When I read through 2560bis, I could not tell if there was an extension which would allow an RP to tell if good actually meant a cert was on the white list (and to know the responder has the white list), or merely not on the black list. (Yes, I'm repeating myself. Am I making more sense, or just wasting everyone's time?) /Stefan On 4/8/13 9:35 PM, Henry B. Hotz h...@jpl.nasa.gov wrote: Actually, what I get from this and all the other discussions is that it's unclear if the updated OCSP satisfies the suitability for the intended purpose test. Or at least it fails the KISS principle w.r.t. that. Rephrasing: an OCSP client should be able to tell from an OCSP response if: a) the subject cert is on the CAs white list, b) the subject cert is on the CAs black list, c) the subject cert is not on either list, or finally d) the OCSP server is obsolete, and doesn't support making those distinctions. It's not trivial to see how to parse 2560bis responses w.r.t. those cases, therefore it's highly likely that computational complexity will prevent us from doing so. Even if that's not actually the case, then implementor misunderstandings will prevent us from doing so in practice. Therefore I vote against moving this draft forward. I just don't see the point. If someone were to write an informational RFC which explained how to determine which of the 4 cases an OCSP response fell into, AND if said RFC also convinced me that the decision process was easy to understand, THEN I would change my vote. Obviously an appendix in 2560bis would serve just as well. -- The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. henry.b.h...@jpl.nasa.gov, or hbh...@oxy.edu
Re: IETF Diversity Question on Berlin Registration?
On April 12, 2013 2:33:13 PM Melinda Shore melinda.sh...@gmail.com wrote: On 4/12/2013 10:12 AM, Toerless Eckert wrote: I still think that the IETF community at large has no intentional diversity bias, so the process of discussing and analyzing diversity in the context of leadership is to help better describe diversity induced job qualifications as well as uncovering any potential unconscious bias to help overcoming it. I think it's unintentional, as well, but I'm not sure that's *much* of an improvement over malicious bias. It certainly makes it far, far, far more difficult to address. As I said I think that looking at the pool of nominees who've accepted their nominations and comparing it to the pool of people selected would provide one very rough measure of bias (explicit or otherwise) in one stage of the process. While I've been very reluctant to jump on this topic, I have to ask what's the basis for this assertion? A willingness to do/volunteer for a job says nothing about one's qualifications for a job. Now if we somehow could compare 'qualified' nominees vs selected, I'd agree that that could be interesting Lou Melinda
Re: IETF Diversity Question on Berlin Registration?
On 4/12/2013 11:04 AM, Lou Berger wrote: While I've been very reluctant to jump on this topic, I have to ask what's the basis for this assertion? I think the numbers are pretty compelling, which is why I think they would deserve scrutiny if there's the possibility of remediation if a problem is identified. However, it's pretty clear from the tone of the discussion so far that no remediation would be possible, and so I actually think it's probably a bad idea to attack the question. That does not mean, however, that the question does not exist. And I don't know if you intended to or not, but what you communicated is The best candidates are nearly always western white guys, since that's who's being selected. That's a problematic suggestion. Melinda
Re: Purpose of IESG Review
How can a memebr of staff in a company argue with the manager about the manager's decisions or performance? Only Owners/shareholders can question managers and staff. IMO, the meeting/list discussions on any issue without an I-D written is the staff talking/working. If you write an I-D and to update the procedure related to the subject, you should consider many issues and I think will need many years of discussions, but then better effort result. IMHO, writing an I-D and getting back up by community discussion (with rough consensus) is in the top level and is the owner talking. I hope that when I review and comment on an I-D, it should be considered as one owner is talking, but seems like editors think they are the only owners. When IESG comment on the I-D it is managers/excutives talking. All parts are important to the best of output. AB On Fri, Apr 12, 2013 at 10:33 AM, Abdussalam Baryun abdussalambar...@gmail.com wrote: Reply to below message The subject SHOULD be: Evaluating Review Process Performance I prefer the Subject is: Evaluating WG input, the WG review process, and the WG output, NOT IESG review. Hi Joe, My comments mostly is on your message, but I comment also on I-Ds or RFCs related to IETF (including joky RFCs). I don't think it is write to evaluate the review of an IESG as long as when we created the I-D and adopted it into IETF SYSTEM, it is already agreeing on the methods of process that I-D is going through. So the problem is to evaluate three things not one: 1) the input, 2) the process review, 3) the output. We may make different input methods that go to another body than IESG, but if you decided to make I-D under IETF current procedure, it will have to go to IESG. I think the IESG are doing an excellent job, but it is best them to evaluate their performance not the community. Or it is better to find a body that evaluates the IESG performance not on this list. I consider your input on the list as a complain about the process, so I ask you to notice that your input has an error that needs evaluation befor going to process evaluation. You may evaluate output, but I remind you to evaluate input of WGs and inputs of individuals. I think the BIG problem of delay in I-Ds or RFC, is the cause of the WG not the IESG, if you do an excellent WG processes you will get quick results at IESG. AB + Hi, all, As an author who has had (and has) multiple documents in IESG review, I've noticed an increasing trend of this step to go beyond (IMO) its documented and original intent (BCP 9, currently RFC 2026): The IESG shall determine whether or not a specification submitted to it according to section 6.1.1 satisfies the applicable criteria for the recommended action (see sections 4.1 and 4.2), and shall in addition determine whether or not the technical quality and clarity of the specification is consistent with that expected for the maturity level to which the specification is recommended. Although I appreciate that IESG members are often overloaded, and the IESG Review step is often the first time many see these documents, I believe they should be expected to more clearly differentiate their IESG Review (based on the above criteria) - and its accompanying Position ballot, with their personal review. My concern is that by conflating their IESG position with their personal review, the document process is inappropriately delayed and that documents are modified to appease a small community that does not justify its position as representative. How do others feel about this? Joe
Re: Purpose of IESG Review
Not answering any particular post. Just a comment. The IESG should be there to attest that the IETF procedure was followed and the document reached consensus in the WG and in the IETF LC and it was successfully reviewed by the Gen-ART. If it wasn't then this particular process should be reviewed and take actions accordingly (e.g. returning the document to the wg). But if a single individual of the IESG can technically challenge and change the work of a whole WG and the IETF, then we have something wrong in our process because that means that the document had a serious problem and we didn't spot it in the process or an IESG member is using its power to change a document according to its personal beliefs. Just a thought, as On 4/11/13 2:54 PM, Joe Touch wrote: Hi, all, As an author who has had (and has) multiple documents in IESG review, I've noticed an increasing trend of this step to go beyond (IMO) its documented and original intent (BCP 9, currently RFC 2026): The IESG shall determine whether or not a specification submitted to it according to section 6.1.1 satisfies the applicable criteria for the recommended action (see sections 4.1 and 4.2), and shall in addition determine whether or not the technical quality and clarity of the specification is consistent with that expected for the maturity level to which the specification is recommended. Although I appreciate that IESG members are often overloaded, and the IESG Review step is often the first time many see these documents, I believe they should be expected to more clearly differentiate their IESG Review (based on the above criteria) - and its accompanying Position ballot, with their personal review. My concern is that by conflating their IESG position with their personal review, the document process is inappropriately delayed and that documents are modified to appease a small community that does not justify its position as representative. How do others feel about this? Joe
Re: Purpose of IESG Review
On 4/12/2013 11:28 AM, Arturo Servin wrote: But if a single individual of the IESG can technically challenge and change the work of a whole WG and the IETF, then we have something wrong in our process because that means that the document had a serious problem and we didn't spot it in the process or an IESG member is using its power to change a document according to its personal beliefs. We've had that happen in a working group I chair and I do think that it was the result of process failure in the working group. That said, there seemed to be broad agreement across the IESG that the document had certain specific flaws - I do think there's a problem if a single IESG member can reject working group consensus and hold up a document - it seems as if there should be wider agreement that the document is too flawed to progress. Melinda
The Purpose of WG participants Review (was Re: Purpose of IESG Review)
I just change the subject because I still beleive the problem with review is in the WG not IESG. Some WGs have few reviews on each WG document, that may not be bad, but I think having only one review or comment (excluding authors) within a WGLC is wrong in a WG review process. I think WG chair can find two participants to do it. I recommend WG's process to change their purpose so we have to get *two participants* which are not authors to review the work and comment within WGLC (even small text comment is ok). I recommend WG chairs to think about this proposal, if not then I will try write an I-D for this and communicate with community. AB On Fri, Apr 12, 2013 at 8:24 PM, Abdussalam Baryun abdussalambar...@gmail.com wrote: How can a memebr of staff in a company argue with the manager about the manager's decisions or performance? Only Owners/shareholders can question managers and staff. IMO, the meeting/list discussions on any issue without an I-D written is the staff talking/working. If you write an I-D and to update the procedure related to the subject, you should consider many issues and I think will need many years of discussions, but then better effort result. IMHO, writing an I-D and getting back up by community discussion (with rough consensus) is in the top level and is the owner talking. I hope that when I review and comment on an I-D, it should be considered as one owner is talking, but seems like editors think they are the only owners. When IESG comment on the I-D it is managers/excutives talking. All parts are important to the best of output. AB On Fri, Apr 12, 2013 at 10:33 AM, Abdussalam Baryun abdussalambar...@gmail.com wrote: Reply to below message The subject SHOULD be: Evaluating Review Process Performance I prefer the Subject is: Evaluating WG input, the WG review process, and the WG output, NOT IESG review. Hi Joe, My comments mostly is on your message, but I comment also on I-Ds or RFCs related to IETF (including joky RFCs). I don't think it is write to evaluate the review of an IESG as long as when we created the I-D and adopted it into IETF SYSTEM, it is already agreeing on the methods of process that I-D is going through. So the problem is to evaluate three things not one: 1) the input, 2) the process review, 3) the output. We may make different input methods that go to another body than IESG, but if you decided to make I-D under IETF current procedure, it will have to go to IESG. I think the IESG are doing an excellent job, but it is best them to evaluate their performance not the community. Or it is better to find a body that evaluates the IESG performance not on this list. I consider your input on the list as a complain about the process, so I ask you to notice that your input has an error that needs evaluation befor going to process evaluation. You may evaluate output, but I remind you to evaluate input of WGs and inputs of individuals. I think the BIG problem of delay in I-Ds or RFC, is the cause of the WG not the IESG, if you do an excellent WG processes you will get quick results at IESG. AB + Hi, all, As an author who has had (and has) multiple documents in IESG review, I've noticed an increasing trend of this step to go beyond (IMO) its documented and original intent (BCP 9, currently RFC 2026): The IESG shall determine whether or not a specification submitted to it according to section 6.1.1 satisfies the applicable criteria for the recommended action (see sections 4.1 and 4.2), and shall in addition determine whether or not the technical quality and clarity of the specification is consistent with that expected for the maturity level to which the specification is recommended. Although I appreciate that IESG members are often overloaded, and the IESG Review step is often the first time many see these documents, I believe they should be expected to more clearly differentiate their IESG Review (based on the above criteria) - and its accompanying Position ballot, with their personal review. My concern is that by conflating their IESG position with their personal review, the document process is inappropriately delayed and that documents are modified to appease a small community that does not justify its position as representative. How do others feel about this? Joe
Re: IETF Diversity Question on Berlin Registration?
Hi Spencer, At 07:38 12-04-2013, Spencer Dawkins wrote: I was just checking the math. I understand. :-) I couldn't possibly say what good means, and I'm interested in better understanding what diverse means, to this, ummm, at least somewhat diverse community ... There is an underlying uneasiness. It has probably been there for a while. Five women went to the microphone to openly raise an issue. Some individuals from the IETF community understood that the issue would not go away. The word diverse is currently used as a placeholder for the issue. I asked [1] the IETF Administrative Oversight Committee (IAOC) what their definition of diversity is as, as good engineers, the IAOC [2] would like to measure it. Hannes Tschofenig once said that nowadays everyone claims to be open and transparent [3]. What was visible at a plenary was that there was one woman within a group of men facing a larger group in which there are only a few women. There was also something else which was visible. My guess is that it is a case of what I say and what I do are two different things. Douglas Otis mentioned that outcomes, good or bad, are often influenced by groups sharing a common interest. Important questions should attempt to measure whether these interests reflect those of the larger Internet communities [4]. Let's take IAOC members as an example. NomCom chose two men from the United States. The IAB chose a man from the United States. The IESG chose a man from the United States. The ISOC Board of Trustees chose a man from the United States. There is a chart of IETF attendance by regions for the last seven meetings. There isn't any publicly available information about attendance by men and women. It's going to be difficult to argue that the IAOC reflects the interests of the IETF community unless a very large number of participants are men from the United States. There hasn't been a woman on the IESG since 2009. The last time there were two women on the IESG was in 2005. There has been one or two women on the IAB over the years. p.s. And I wasn't trying to be snarky about the math. I blew the percentages in the first draft of my response, so I know it happens to the best of us :-) Don't worry about that, I did not read it as snarky or anything negative. :-) Regards, -sm 1. http://www.ietf.org/mail-archive/web/ietf/current/msg78592.html 2. http://www.ietf.org/mail-archive/web/ietf/current/msg78551.html 3. http://www.ietf.org/mail-archive/web/ietf/current/msg62409.html 4. http://www.ietf.org/mail-archive/web/ietf/current/msg78603.html
Re: IETF Diversity Question on Berlin Registration?
On Fri, Apr 12, 2013 at 10:33:13AM -0800, Melinda Shore wrote: address. As I said I think that looking at the pool of nominees who've accepted their nominations and comparing it to the pool of people selected would provide one very rough measure of bias (explicit or otherwise) in one stage of the process. Speaking only personally, but as one of the fat middle-aged white men from North America whose mother tongue is English, and as someone who was selected by the Nomcom for something this year, I strongly support the above. It would not be a result to give us anything remotely like hard data, but it would be a result that could suggest further inquiry. And it oughta be cheap to generate. As long as we use it carefully, such a result could be useful. A -- Andrew Sullivan a...@anvilwalrusden.com
Re: Purpose of IESG Review
On 4/12/13 4:32 PM, Melinda Shore wrote: On 4/12/2013 11:28 AM, Arturo Servin wrote: But if a single individual of the IESG can technically challenge and change the work of a whole WG and the IETF, then we have something wrong in our process because that means that the document had a serious problem and we didn't spot it in the process or an IESG member is using its power to change a document according to its personal beliefs. We've had that happen in a working group I chair and I do think that it was the result of process failure in the working group. That said, there seemed to be broad agreement across the IESG that the document had certain specific flaws I think that exemplifies well what the IESG should do. - I do think there's a problem if a single IESG member can reject working group consensus and hold up a document - it seems as if there should be wider agreement that the document is too flawed to progress. Melinda Yes. Best wishes, as
Re: The Purpose of WG participants Review (was Re: Purpose of IESG Review)
On 4/12/13 4:58 PM, Abdussalam Baryun wrote: I just change the subject because I still beleive the problem with review is in the WG not IESG. Some WGs have few reviews on each WG document, that may not be bad, but I think having only one review or comment (excluding authors) within a WGLC is wrong in a WG review process. I think WG chair can find two participants to do it. It seems plausible. I recommend WG's process to change their purpose so we have to get *two participants* which are not authors to review the work and comment within WGLC (even small text comment is ok). I recommend WG chairs to think about this proposal, if not then I will try write an I-D for this and communicate with community. Possible we would need any how an I+D to change the process and mandate this new review. I haven't made my mind but it seems like a good idea. AB Regards as
Re: IETF Diversity Question on Berlin Registration?
At 02:11 PM 4/12/2013, Melinda Shore wrote: And I don't know if you intended to or not, but what you communicated is The best candidates are nearly always western white guys, since that's who's being selected. That's a problematic suggestion. I respect you, Melinda. I think you are smarter and more technically and philosophically qualified than me. Having said that, what Lou asked was an honest question, yet you seemed to take it in the worst possible way. I'd say each of us is likely bringing our own baggage to how we each look at this 'problem', if there is a problem at all (which doesn't appear to be universally agreed upon). since that's who's being selected is a biased observation in and of itself. That's saying that because of the outcome, there has to be bias to skew the results this way - because it's the only logical explanation that could answer these results. My BS-meter is pegging into the red on that one. The nomcom isn't randomly picking hats in a crowd. They are picking talent of those that have volunteered to serve. At any given time there could be 1 or 2 or 5 women how volunteered to server at particular AD slot, but there might be 1 white guy that is more qualified. From the audience at any plenary - that could appear the fix is in to ace out the women, but clearly (in this hypothetical example) it's not the case at all. Eyeballing the IETF (and I've missed 2 meetings since IETF45, been a WG chair for 8 years, and written or revised over 300 submitted IDs) there is consistently about a 70-to-1 ratio of men to women. I'd observe that this is likely the case of hurt feelings rather than unqualified males achieving the AD position in lieu of more qualified females - especially in the face of these rough ratio approximations. I believe we need to reduce that ratio, and am for anything that increases the number of (qualified) women in this engineering organization. I am against artificially forcing the nomcom to implement a quota system to overcome low participation numbers of any diversity aspect. Admittedly, I'm only teasing out the male/female diversity facet, and not any other the other - equally deserving diversity criteria. James
Re: Purpose of IESG Review
- Original Message - From: Arturo Servin arturo.ser...@gmail.com To: ietf@ietf.org Sent: Friday, April 12, 2013 8:28 PM Not answering any particular post. Just a comment. The IESG should be there to attest that the IETF procedure was followed and the document reached consensus in the WG and in the IETF LC and it was successfully reviewed by the Gen-ART. If it wasn't then this particular process should be reviewed and take actions accordingly (e.g. returning the document to the wg). But if a single individual of the IESG can technically challenge and change the work of a whole WG and the IETF, then we have something wrong in our process because that means that the document had a serious problem and we didn't spot it in the process or an IESG member is using its power to change a document according to its personal beliefs. My experience has been the former, where the IESG has raised concerns about arcane topics, such as security and congestion, of which the WG had limited expertise. This might be caught by a directorate review, but those seem patchy; it might be caught by IETF Last Call, but if you are an expert at an arcane topic then you are probably too busy to follow them. So I do see the IESG DISCUSSing, when it would have been lovely to have had, but it is hard to see quite how, it resolved earlier. We just do not have the breadth of knowledge of arcane topics. Tom Petch Just a thought, as On 4/11/13 2:54 PM, Joe Touch wrote: Hi, all, As an author who has had (and has) multiple documents in IESG review, I've noticed an increasing trend of this step to go beyond (IMO) its documented and original intent (BCP 9, currently RFC 2026): The IESG shall determine whether or not a specification submitted to it according to section 6.1.1 satisfies the applicable criteria for the recommended action (see sections 4.1 and 4.2), and shall in addition determine whether or not the technical quality and clarity of the specification is consistent with that expected for the maturity level to which the specification is recommended. Although I appreciate that IESG members are often overloaded, and the IESG Review step is often the first time many see these documents, I believe they should be expected to more clearly differentiate their IESG Review (based on the above criteria) - and its accompanying Position ballot, with their personal review. My concern is that by conflating their IESG position with their personal review, the document process is inappropriately delayed and that documents are modified to appease a small community that does not justify its position as representative. How do others feel about this? Joe
Re: IETF Diversity Question on Berlin Registration?
On Apr 12, 2013, at 4:01 PM, SM s...@resistor.net wrote: Let's take IAOC members as an example. NomCom chose two men from the United States. The IAB chose a man from the United States. The IESG chose a man from the United States. The ISOC Board of Trustees chose a man from the United States. There is a chart of IETF attendance by regions for the last seven meetings. There isn't any publicly available information about attendance by men and women. It's going to be difficult to argue that the IAOC reflects the interests of the IETF community unless a very large number of participants are men from the United States. I'd like to take slight exception to one thing that this paragraph implies: that only a person who looks like me and comes from the same region can represent my interests. I realize that given that I happen to be a white male from the United States, the world's smallest violin is playing somewhat unenthusiastically on my behalf at the moment. But in fact I would object quite strongly to another white male from the United States representing me rather than a non-white, non-male not from the United States with whom I shared more views in common. And this is not a matter of purely academic interest: there are many white males from the United States whose views I find vary across the range from puzzling to upsetting. So in fact you don't need to put some percentage of white males on the IESG, the IAB or the IAOC to make me happy. I want people on these bodies who feel strongly about open standards, rough consensus and running code. That's the kool-aid I have drunk, and I want them to have drunk it too.
Re: Purpose of IESG Review
On 4/12/13 5:52 PM, t.p. wrote: - Original Message - From: Arturo Servin arturo.ser...@gmail.com To: ietf@ietf.org Sent: Friday, April 12, 2013 8:28 PM Not answering any particular post. Just a comment. The IESG should be there to attest that the IETF procedure was followed and the document reached consensus in the WG and in the IETF LC and it was successfully reviewed by the Gen-ART. If it wasn't then this particular process should be reviewed and take actions accordingly (e.g. returning the document to the wg). But if a single individual of the IESG can technically challenge and change the work of a whole WG and the IETF, then we have something wrong in our process because that means that the document had a serious problem and we didn't spot it in the process or an IESG member is using its power to change a document according to its personal beliefs. My experience has been the former, where the IESG has raised concerns about arcane topics, such as security and congestion, of which the WG had limited expertise. This might be caught by a directorate review, but those seem patchy; it might be caught by IETF Last Call, but if you are an expert at an arcane topic then you are probably too busy to follow them. So I do see the IESG DISCUSSing, when it would have been lovely to have had, but it is hard to see quite how, it resolved earlier. We just do not have the breadth of knowledge of arcane topics. Perhaps we need an arcane topic reviewer before the LC. .as Tom Petch Just a thought, as On 4/11/13 2:54 PM, Joe Touch wrote: Hi, all, As an author who has had (and has) multiple documents in IESG review, I've noticed an increasing trend of this step to go beyond (IMO) its documented and original intent (BCP 9, currently RFC 2026): The IESG shall determine whether or not a specification submitted to it according to section 6.1.1 satisfies the applicable criteria for the recommended action (see sections 4.1 and 4.2), and shall in addition determine whether or not the technical quality and clarity of the specification is consistent with that expected for the maturity level to which the specification is recommended. Although I appreciate that IESG members are often overloaded, and the IESG Review step is often the first time many see these documents, I believe they should be expected to more clearly differentiate their IESG Review (based on the above criteria) - and its accompanying Position ballot, with their personal review. My concern is that by conflating their IESG position with their personal review, the document process is inappropriately delayed and that documents are modified to appease a small community that does not justify its position as representative. How do others feel about this? Joe
Re: Purpose of IESG Review
--On Friday, April 12, 2013 20:24 +0100 Abdussalam Baryun abdussalambar...@gmail.com wrote: How can a memebr of staff in a company argue with the manager about the manager's decisions or performance? In most successful companies, yes. Only Owners/shareholders can question managers and staff. And companies that behave that way don't last very long in rapidly evolving fields... at least unless the managers are endowed with perfect wisdom. It is not an accident that most management schools teach would-be managers that listening --especially to the people on the front lines-- is a very important skill. So, at the risk of generalizing too much... What on earth are you talking about and what experience do you have and use to justify it? john
Re: IETF Diversity Question on Berlin Registration?
James == James Polk jmp...@cisco.com writes: James The nomcom isn't randomly picking hats in a crowd. They are James picking talent of those that have volunteered to serve. At Volunteered, and who have employer/funding support. The apparent bias that we are experiencing is the result of 30+ years of high-tech employment bias towards the white male. To be a qualified candidate requires a bunch of things: (and I mean qualified in both the qualities of the person, and the various supports needed to do the job) 1) working for a moderate to large company for a sufficiently long time such that the company can spare the salary. (Or being sufficiently well connected that the person can find sponsorship) 2) being able to travel for a week+ at a time. 3) having been able to do (2) for enough years to have met enough people that the person's qualifications have been recognized. and of course: 4) doing actual technical work! that's some serious hurdles. There a bias here towards older people who have been in the same company for a long time, and who either have no children, or had them at least ten years ago. Having a child (and I didn't do the hard work), restricted my ability to travel sufficiently that I wasn't nomcom eligible for 5 years True, we have had people overcome hurdles: at least one IESG baby is expected this year, and we didn't even have a parental leave policy until Lisa wrote one. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ pgpnKkUYgzP5d.pgp Description: PGP signature
Re: IETF Diversity Question on Berlin Registration?
Hi Ted, At 14:06 12-04-2013, Ted Lemon wrote: I'd like to take slight exception to one thing that this paragraph implies: that only a person who looks like me and comes from the same region can represent my interests. I Let's see how many IETF participants (I'll exclude voting members of I* bodies if you are ok with that) share the view mentioned above. I'll take the liberty of not expressing my view. So in fact you don't need to put some percentage of white males on the IESG, the IAB or the IAOC to make me happy. I want people on these bodies who feel strongly about open standards, rough consensus and running code. That's the kool-aid I have drunk, and I Thomas Narten mentioned that: we have the tendency to pick the people we know and trust, which is understandable. How many IAB members feel strongly about open standards, rough consensus and running code? To know the answer I would have to actually know the IAB members. Regards, -sm
RE: Purpose of IESG Review
+1 on for John's response. I will argue with my manager if I think they are wrong and I've gotten positive results from giving managers feedback on their performance. Of course, disagreeing with management won't always get the decision changed, but I've never felt I lost anything by raising the discussion. I've also seen some bad decisions made when someone had good reasons why a decision was wrong but didn't surface them because they didn't feel they could argue with management. IETF participant to IETF leadership isn't the same as employee to manager of course. We are all volunteers collaborating to get good results and if we feel there is a process problem we can discuss it. IETF formalizes this by having open mike sessions for example. A thread on whether there is a problem with the IESG review process is appropriate, IMO. -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of John C Klensin Sent: Friday, April 12, 2013 3:19 PM To: Abdussalam Baryun; ietf Subject: Re: Purpose of IESG Review --On Friday, April 12, 2013 20:24 +0100 Abdussalam Baryun abdussalambar...@gmail.com wrote: How can a memebr of staff in a company argue with the manager about the manager's decisions or performance? In most successful companies, yes. Only Owners/shareholders can question managers and staff. And companies that behave that way don't last very long in rapidly evolving fields... at least unless the managers are endowed with perfect wisdom. It is not an accident that most management schools teach would-be managers that listening --especially to the people on the front lines-- is a very important skill. So, at the risk of generalizing too much... What on earth are you talking about and what experience do you have and use to justify it? john
Re: IETF Diversity Question on Berlin Registration?
SM wrote: Ted Lemon wrote: So in fact you don't need to put some percentage of white males on the IESG, the IAB or the IAOC to make me happy. I want people on these bodies who feel strongly about open standards, rough consensus and running code. That's the kool-aid I have drunk, and I Me 2! Thomas Narten mentioned that: we have the tendency to pick the people we know and trust, which is understandable. How many IAB members feel strongly about open standards, rough consensus and running code? To know the answer I would have to actually know the IAB members. I believe there is a problem for human beings that with more choice the picks may get worse, based on an evolutionary cognitive limit. http://en.wikipedia.org/wiki/Dunbar%27s_number http://www.cracked.com/article_14990_what-monkeysphere.html -Martin
Re: IETF Diversity Question on Berlin Registration?
On Apr 12, 2013, at 7:32 PM, SM s...@resistor.net wrote: Thomas Narten mentioned that: we have the tendency to pick the people we know and trust, which is understandable. How many IAB members feel strongly about open standards, rough consensus and running code? To know the answer I would have to actually know the IAB members. Are they really that hard to get to know? A number of them are participating in this conversation. It's certainly hard to get time to sit with them at IETF meetings. I don't know what the workload is like for IAB members, but I think I worked at least an 80 hour week in Orlando.
Re: Last Call: draft-sheffer-running-code-04.txt (Improving Awareness of Running Code: the Implementation Status Section) to Experimental RFC
This dude's ready to ship. Thanks for addressing my earlier comments. Barry On Friday, April 12, 2013, The IESG wrote: The IESG has received a request from an individual submitter to consider the following document: - 'Improving Awareness of Running Code: the Implementation Status Section' draft-sheffer-running-code-04.txt as Experimental RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org javascript:; mailing lists by 2013-05-10. Exceptionally, comments may be sent to i...@ietf.org javascript:; instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes a simple process that allows authors of Internet-Drafts to record the status of known implementations by including an Implementation Status section. This will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, by considering the running code as evidence of valuable experimentation and feedback that has made the implemented protocols more mature. The process in this document is offered as an experiment. Authors of Internet-Drafts are encouraged to consider using the process for their documents, and working groups are invited to think about applying the process to all of their protocol specifications. The authors of this document intend to collate experiences with this experiment and to report them to the community. The file can be obtained via http://datatracker.ietf.org/doc/draft-sheffer-running-code/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-sheffer-running-code/ballot/ No IPR declarations have been submitted directly on this I-D.
Re: IETF Diversity Question on Berlin Registration?
On 4/12/13 1:26 PM, Lou Berger wrote: No argument from me, I'm just asking that a comment/position/question that I don't understand be substantiated. And I'm telling you that I think the numbers are highly suggestive of bias. We can take a swing at getting a very rough handle on that but I'm actually not sure that we should because it appears to be the case that the cost of any remediation that some of us might want to undertake would be higher than the cost of living with bias in the system (this would be the considerable downside to consensus decision-making processes with a very large participant base). And I don't know if you intended to or not, but what you communicated is The best candidates are nearly always western white guys, since that's who's being selected. That's a problematic suggestion. I certainly, in no way, shape, or form intended such an implication. I have not idea how one could read it that way, [ ... ] A (male) friend once said that men are no more likely to notice sexism than fish are to notice water. I think that was far too broad but generally true. If I think that white western men are being selected in disproportion to their presence in the candidate pool, and I do, then telling me that we only choose the best is telling me that white, western men tend to be the best. Pretty much every organization that applauds itself for its meritocratic reward structure (to the extent that an I* gig is a reward) and yet only advances white guys says the same thing. It is a trope, and a familiar one. Melinda
Re: [pkix] Last Call: draft-ietf-pkix-rfc2560bis-15.txt (X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP) to Proposed Standard
Henry B. Hotz wrote: Stefan Santesson ste...@aaa-sec.com wrote: Nothing has changed in this regard. The good response is pretty clear that it by default provides information that the cert is not on a black-list (is not know to be revoked). However, it is also made clear that extensions may be used to expand this default information about the status. This is how it always have been, and still is in RFC 256bis. So a non-issued cert may be good. An rfc2560 OCSP responder might return good status for a not issued cert. That is listed as a caveat in the rfc2560 description for good. The revoked response simply means that the certificate is revoked. Combined with the new extension, it MAY also be used for non-issued certs. So a non-issued cert may be revoked. Yes. That is already possible and fully conforming with rfc2560. It is just not explicitly standardized how to do it. IMO it is preferable to standardize how to do it consistently, rather than letting a thousand flowers bloom on the significantly underspecified rfc2560. It's really as simple as that. I would have thought that what was simple was to say a non-issued cert was unknown, since it's neither known-good, nor known-revoked. That is another permissible response for an rfc2560 OCSP responder. But there is more to consider than just what is permissible by the spec, and that is client behaviour of an installed base that has grown over more than a decade. If a non-marginal fraction of the installed base will either fallback to CRL checking or do a soft-fail (assume good) upon receiving unknown status, then this choice of response might not be very sensible. Is there any collection of extensions which will allow an RP to know, for sure, what value will be returned for a never-issued cert? The two MUSTs at the end of section 2.2 in rfc2560bis-18 plus the MUST contain the responseExtension from section 4.4.8. To facilitate recognizing the revocationTime from the end of section 2.2 rfc2560bis-18, it really ought to be written as UTCTime! from (-18): - MUST specify the revocationTime January 1, 1970, and; to (example): - MUST specify the revocationTime 70010100Z It is only the discussion on this list that is confusing and that has managed turn something really simple into a complicated debate. What *I* find confusing is the apparent degree of belief that it is possible to improve 2560 and simultaneously to maintain backward compatibility. That should only be possible if there are some previously-ignored extensions which alter the semantics of the information --- effectively creating a version 2 protocol. As far as the spec rfc2560 is concerned, this is trivial from a formal perspective since there is hardly any client behaviour defined in rfc2560. But the absence of definition of client behaviour in rfc2560 also limits what kind of behaviour can be added now. In particular, mandating specific behaviour (MUST rather than SHOULD) or prohibiting specific behaviour (MUST NOR rather than SHOULD NOT) is going to be a backwards incompatible change, and unless there is a really convincing rationale for addition of MUST / MUST NOT behaviour, this will result in a conflict with rfc2119 Section 6! http://tools.ietf.org/html/rfc2119#section-6 I don't find the claim that nothing has changed helpful. The claim that nothing has changed is provably untrue as long as the imperative MUST for using the Extension in section 4.4.8 of rfc2560bis-18 persists. What I would find helpful, and what I think some people really would like, is for OCSP to be able to provide white-list information in addition to the previous black-list information. When I read through 2560bis, I could not tell if there was an extension which would allow an RP to tell if good actually meant a cert was on the white list (and to know the responder has the white list), or merely not on the black list. (Yes, I'm repeating myself. Am I making more sense, or just wasting everyone's time?) You're correct, a white-list confirmation is not in rfc2560bis. There seem to be white-list confirmations in current use as OCSP extensions for some Qualified Electronic Signature (QES) usage scenarios, but the PKIX WG constituency in favour of the rfc2560 defects prevented that any existing solutions would be adopted for rfc2560bis. The technical issue with white-listing is, that the original claim about the OCSP protocol properties is technically wrong. rfc2560 OCSP, just like CRLs, is _not_ about the status of certificates, it is purely about the status of certificate serial numbers. In order to obtain a technically sound white-listing response, the good response will have to include a certificate hash in an OCSP singleResponse extension, not just a mere serial number. And that seems to be the solution adopted by some existing QES usage scenarios. Since such solutions exist, adopting one of those in
RE: Purpose of IESG Review
If you think security and congestion are arcane, you have... problems. This was an actual ietf working geoup, and not some e.g. W3c thing? Lloyd Wood http://sat-net.com/L.Wood/ From: ietf-boun...@ietf.org [ietf-boun...@ietf.org] On Behalf Of t.p. [daedu...@btconnect.com] Sent: 12 April 2013 21:52 To: Arturo Servin; ietf@ietf.org Subject: Re: Purpose of IESG Review - Original Message - From: Arturo Servin arturo.ser...@gmail.com To: ietf@ietf.org Sent: Friday, April 12, 2013 8:28 PM Not answering any particular post. Just a comment. The IESG should be there to attest that the IETF procedure was followed and the document reached consensus in the WG and in the IETF LC and it was successfully reviewed by the Gen-ART. If it wasn't then this particular process should be reviewed and take actions accordingly (e.g. returning the document to the wg). But if a single individual of the IESG can technically challenge and change the work of a whole WG and the IETF, then we have something wrong in our process because that means that the document had a serious problem and we didn't spot it in the process or an IESG member is using its power to change a document according to its personal beliefs. My experience has been the former, where the IESG has raised concerns about arcane topics, such as security and congestion, of which the WG had limited expertise. This might be caught by a directorate review, but those seem patchy; it might be caught by IETF Last Call, but if you are an expert at an arcane topic then you are probably too busy to follow them. So I do see the IESG DISCUSSing, when it would have been lovely to have had, but it is hard to see quite how, it resolved earlier. We just do not have the breadth of knowledge of arcane topics. Tom Petch Just a thought, as On 4/11/13 2:54 PM, Joe Touch wrote: Hi, all, As an author who has had (and has) multiple documents in IESG review, I've noticed an increasing trend of this step to go beyond (IMO) its documented and original intent (BCP 9, currently RFC 2026): The IESG shall determine whether or not a specification submitted to it according to section 6.1.1 satisfies the applicable criteria for the recommended action (see sections 4.1 and 4.2), and shall in addition determine whether or not the technical quality and clarity of the specification is consistent with that expected for the maturity level to which the specification is recommended. Although I appreciate that IESG members are often overloaded, and the IESG Review step is often the first time many see these documents, I believe they should be expected to more clearly differentiate their IESG Review (based on the above criteria) - and its accompanying Position ballot, with their personal review. My concern is that by conflating their IESG position with their personal review, the document process is inappropriately delayed and that documents are modified to appease a small community that does not justify its position as representative. How do others feel about this? Joe
Re: IETF Diversity Question on Berlin Registration?
On 4/12/2013 8:51 PM, Ted Lemon wrote: On Apr 12, 2013, at 7:32 PM, SM s...@resistor.net wrote: Thomas Narten mentioned that: we have the tendency to pick the people we know and trust, which is understandable. How many IAB members feel strongly about open standards, rough consensus and running code? To know the answer I would have to actually know the IAB members. Are they really that hard to get to know? A number of them are participating in this conversation. It's certainly hard to get time to sit with them at IETF meetings. I don't know what the workload is like for IAB members, but I think I worked at least an 80 hour week in Orlando. So, I can only answer for one IAB member ... I'm less busy during IETF weeks than most IESG members. It happens that SM grabbed me for at least one extended conversation in the hallway in Orlando (he grabbed me for several conversations, but not all of them lasted half an hour), and I found that conversation very helpful from my side. Again, for myself - I see my role as an IAB member to be as helpful as I can be, so answering questions is something I do, and I need to do more often. There are places I have to be, during IETF weeks - for instance, we were interviewing ISOC Board of Trustee nominees at specific times - but there are places I'm going that I don't have to get to, if someone needs to talk with me. Finally - there are people on the IAB with fabulous social skills, but I'm not one of them. If someone needs to spend time picking my brain, I usually do have multiple meals open during IETF week. Spencer
Re: [OPSEC] Last Call: draft-ietf-opsec-ipv6-implications-on-ipv4-nets-03.txt (Security Implications of IPv6 on IPv4 Networks) to Informational RFC
Hi, Brian, On 04/10/2013 01:06 PM, Brian E Carpenter wrote: For simplicity sake (and because I'm not sure how one would tone that one down), my suggestion would be to apply you proposed text, modulo that sentence. Would that be okay with you? -- If not, please do let me know, so that we can try to find a way forward that keeps everyone happy. Well, it's not for me to call the consenus, but with that sentence removed I would personally enter the no objection state. Good. BTW, it's unclear to me whether I should keep in in the acks or not... so please do let me know how you'd like me to proceed in this respect. P.S.: For any other future reviews: I usually do my best to address others' comments. In the event that you submit feedback, and it looks like I have not tried to address it, please resend/ping me (most likely I tried but failed, the feedback slipped by, or whatever... ) Thanks! Best regards, -- Fernando Gont SI6 Networks e-mail: fg...@si6networks.com PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
Re: IETF Diversity Question on Berlin Registration?
On Fri, Apr 12, 2013 at 06:22:17PM -0800, Melinda Shore wrote: to be the best. Pretty much every organization that applauds itself for its meritocratic reward structure (to the extent that an I* gig is a reward) and yet only advances white guys says the same thing. Speaking only personally, I tend to agree with the above. Despite my earlier remark that I think it'd be good to get a rough idea about the size of the problem, I'm not sure what to do about it. I'm particularly worried that I'm going to get to live through a repeat experience. The following is a cautionary tale, cartoonish but not so far from the way I observed it. In the parts of Canada where I lived in the 1990s, philosophy departments (which had truly abysmal numbers of female faculty) decided there was a shortage of female faculty -- despite the facts that they'd always promoted only the best, were all sooper-rational detached unbiased people, and so on. The problem was, of course, made considerably worse by the tenure system, which (owing to the quirks of the historic expansion of departments) meant that an overwhelming number of tenured faculty were roughly the same age. In any case, the Canadian Philosophical Association and, correspondingly, most departments decided to adopt a principle that, whenever there was an open spot, if there were two qualified people and one of them was a woman, the woman should be chosen. You can imagine the effect. A large number of (usually in my experience truly mediocre) male PhDs concluded that the only reason they didn't get a tenured job was because there were quotas. (It certainly had nothing to do with the overabundance of mediocre PhDs in philosophy.) Meanwhile, any woman who wasn't doing things from a feminist perspective was automatically pegged as some sort of toady trying to get in good with the patriarchy in order to get her portion of the quota. Deeply sexist men who went around enforcing the girls do girl-philsophy, not this hard stuff I do could congratulate themselves for being open minded and non-sexist, even if they made jaw-droppingly obscene remarks to female students. The entire atmosphere was poisoned. None of this was the reason I quit my doctoral program (I was one of the mediocrities), but it sure didn't count as a reason to stay. The only lesson I really learned from that experience is that it is incredibly hard for women[1] to be treated as adult colleagues in an environment that acts overwhelmingly as a white male club. I still have no idea how to do anything about it except to try to be super attentive to the problem all the time. That's why I'd like us to have an idea of roughly how badly we're doing: then we can pay attention to our weaknesses in an effort to turn such attention into a strength. [1] In this case, but I actually think this generalizes to other groups pretty well. A -- Andrew Sullivan a...@anvilwalrusden.com
Re: IETF Diversity Question on Berlin Registration?
Andrew Sullivan a...@anvilwalrusden.com wrote:
On Fri, Apr 12, 2013 at 06:22:17PM -0800, Melinda Shore wrote:
to be the best. Pretty much every organization that applauds
itself for its meritocratic reward structure (to the extent
that an I* gig is a reward) and yet only advances white
guys says the same thing.
Speaking only personally, I tend to agree with the above. Despite my
earlier remark that I think it'd be good to get a rough idea about the
size of the problem, I'm not sure what to do about it. I'm
particularly worried that I'm going to get to live through a repeat
experience. The following is a cautionary tale, cartoonish but not so
far from the way I observed it.
In the parts of Canada where I lived in the 1990s, philosophy
departments (which had truly abysmal numbers of female faculty)
decided there was a shortage of female faculty -- despite the facts
that they'd always promoted only the best, were all sooper-rational
detached unbiased people, and so on. The problem was, of course, made
considerably worse by the tenure system, which (owing to the quirks of
the historic expansion of departments) meant that an overwhelming
number of tenured faculty were roughly the same age. In any case, the
Canadian Philosophical Association and, correspondingly, most
departments decided to adopt a principle that, whenever there was an
open spot, if there were two qualified people and one of them was a
woman, the woman should be chosen.
You can imagine the effect. A large number of (usually in my
experience truly mediocre) male PhDs concluded that the only reason
they didn't get a tenured job was because there were quotas. (It
certainly had nothing to do with the overabundance of mediocre PhDs in
philosophy.) Meanwhile, any woman who wasn't doing things from a
feminist perspective was automatically pegged as some sort of toady
trying to get in good with the patriarchy in order to get her portion
of the quota. Deeply sexist men who went around enforcing the
girls do girl-philsophy, not this hard stuff I do could congratulate
themselves for being open minded and non-sexist, even if they made
jaw-droppingly obscene remarks to female students. The entire
atmosphere was poisoned. None of this was the reason I quit my
doctoral program (I was one of the mediocrities), but it sure didn't
count as a reason to stay.
The only lesson I really learned from that experience is that it is
incredibly hard for women[1] to be treated as adult colleagues in an
environment that acts overwhelmingly as a white male club. I still
have no idea how to do anything about it except to try to be super
attentive to the problem all the time. That's why I'd like us to have
an idea of roughly how badly we're doing: then we can pay attention to
our weaknesses in an effort to turn such attention into a strength.
[1] In this case, but I actually think this generalizes to other
groups pretty well.
I've seen similar things in other contexts too. I'd suggest turning the
question around. I don't think the question of if there is bias or not is
reasonably measurable.
There is also a reasonable body of evidence that people who are in a small
minority will tend to feel unwelcome regardless of if there are any actual bias
or barriers.
Rather the engage in navel gazing about bias detection, engage in finding ways
to engage in encouraging more participation from ${group}.
The question to ask is What can the IETF do to be more open/inviting?
Scott K
Last Call: draft-ietf-6man-stable-privacy-addresses-06.txt (A method for Generating Stable Privacy-Enhanced Addresses with IPv6 Stateless Address Autoconfiguration (SLAAC)) to Proposed Standard
The IESG has received a request from the IPv6 Maintenance WG (6man) to consider the following document: - 'A method for Generating Stable Privacy-Enhanced Addresses with IPv6 Stateless Address Autoconfiguration (SLAAC)' draft-ietf-6man-stable-privacy-addresses-06.txt as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2013-04-26. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document specifies a method for generating IPv6 Interface Identifiers to be used with IPv6 Stateless Address Autoconfiguration (SLAAC), such that addresses configured using this method are stable within each subnet, but the Interface Identifier changes when hosts move from one network to another. The aforementioned method is meant to be an alternative to generating Interface Identifiers based on IEEE identifiers, such that the benefits of stable addresses can be achieved without sacrificing the privacy of users. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-6man-stable-privacy-addresses/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-6man-stable-privacy-addresses/ballot/ No IPR declarations have been submitted directly on this I-D.
Protocol Action: 'Duplicate Address Detection Proxy' to Proposed Standard (draft-ietf-6man-dad-proxy-07.txt)
The IESG has approved the following document: - 'Duplicate Address Detection Proxy' (draft-ietf-6man-dad-proxy-07.txt) as Proposed Standard This document is the product of the IPv6 Maintenance Working Group. The IESG contact persons are Brian Haberman and Ted Lemon. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-6man-dad-proxy/ Technical Summary The document describes a proxy based mechanism allowing the use of Duplicate Address Detection (DAD) by IPv6 nodes in a point-to- multipoint architecture with split-horizon forwarding scheme, primarily deployed for Digital Subscriber Line (DSL) and Fiber access architectures. Based on the DAD signalling, the first hop router stores in a Binding Table all known IPv6 addresses used on a point- to-multipoint domain (e.g. VLAN). When a node performs DAD for an address already used by another node, the first hop router replies instead of this last one. Working Group Summary The working group has reviewed and discussed this draft, feel it solves a relevant problem, and supports it becoming a standard. Document Quality This document has been reviewed by many people and the chairs believe there is agreement in the w.g. to move it forward. Personnel Bob Hinden is the Document Shepherd. Brian Haberman is the Responsible Area Director. RFC Editor Note OLD: When a node performs DAD for an address already used by another node, the first hop router replies instead of this last one. NEW: When a node performs DAD for an address already used by another node, the first hop router defends the address rather than the device using the address.
New Non-WG Mailing List: mif-arch-dt -- MIF Architecture Design Team mailing list
A new IETF non-working group email list has been created. List address: mif-arch...@ietf.org Archive: http://www.ietf.org/mail-archive/web/mif-arch-dt/current/maillist.html To subscribe: https://www.ietf.org/mailman/listinfo/mif-arch-dt Purpose: This list is for the MIF Architecture Design Team, a group of volunteers that are working on an architecture document for consideration by the IETF Multiple Interfaces (mif) Working Group. Although the list is limited to design team volunteers, the archive is open to anyone who would like to read it. For additional information, please contact the list administrators.
New Non-WG Mailing List: diversity -- Diversity design team mailing list
A new IETF non-working group email list has been created. List address: divers...@ietf.org Archive: http://www.ietf.org/mail-archive/web/diversity/current/maillist.html To subscribe: https://www.ietf.org/mailman/listinfo/diversity Purpose: The diversity design team will work on identifying diversity related issues that the IETF faces and making practical recommendations that can help in this regard. This mailing list will be used for obtaining input from the community as well as for working discussions within the design team. For additional information, please contact the list administrators.
Last Call: draft-sheffer-running-code-04.txt (Improving Awareness of Running Code: the Implementation Status Section) to Experimental RFC
The IESG has received a request from an individual submitter to consider the following document: - 'Improving Awareness of Running Code: the Implementation Status Section' draft-sheffer-running-code-04.txt as Experimental RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2013-05-10. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes a simple process that allows authors of Internet-Drafts to record the status of known implementations by including an Implementation Status section. This will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, by considering the running code as evidence of valuable experimentation and feedback that has made the implemented protocols more mature. The process in this document is offered as an experiment. Authors of Internet-Drafts are encouraged to consider using the process for their documents, and working groups are invited to think about applying the process to all of their protocol specifications. The authors of this document intend to collate experiences with this experiment and to report them to the community. The file can be obtained via http://datatracker.ietf.org/doc/draft-sheffer-running-code/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-sheffer-running-code/ballot/ No IPR declarations have been submitted directly on this I-D.
