Gen-ART LC review of draft-ietf-netmod-interfaces-cfg-10
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-netmod-interfaces-cfg-10 Reviewer: Roni Even Review Date:2013-4-28 IETF LC End Date: 2013-5-3 IESG Telechat date: 2013-5-16 Summary: This draft is almost ready for publication as Standard track RFC. Major issues: Minor issues: 1. I had some problem understanding the location leaf. Section 3.2 has it as a string and says that The device uses the location string to identify the physical or logical entity that the configuration applies to. I am not sure how you identify physical location having no definition of the mapping. I saw the examples in Appendix E and it looked more to me as logical mapping but not physical since it attaches a name to something in the device but I am not clear how you know what it is physically in the device. If the name 0-n or n/m are real physical entities, I think that it should be specified some place. Nits/editorial comments: 1. In the introduction section maybe add to the first sentence a reference to RFC6244 with some text. 2. In section 2 are the must and should used as described in RFC2119, if yes need capital letters 3. In section 3.1 It is optional in the data model, but if the type represents a physical interface, it is mandatory, suggest having RFC2119 language It is OPTIONAL in the data model, but if the type represents a physical interface, it is MUST be specified
Re: Biggest Fake Conference in Computer Science
Hi Thanks for your input, and I comment on your post that it is always important to listen to reviews, and try to understand reviewers (even if they may be stupid, or have wrong comments), any world/community editor or author should be careful to listen and understand to comments, to make their work clarified, true and up to date. A conference or document maybe noticed as a fake/humerous/joky only if it gets reviewed by the world and commented on in public, in that way the world can be aware. That is why I like the IETF that its documents are Request For Comment (RFC), different from other world published documents. If I am a chairman of a conference I will name its publications RFC as well :) I got once a reply on my review in an IETF WG that it was academic not practical (I never distiguish them because I beleive they are married), which I think we need all kinds of reviews, I like to include comments as was this implemented or measured its performance (by questioning authors). Reviewing any document in the world (which will be published in the world) is not an easy task and also important for authors to respect and acknowledge such review because it increases reputation and saves them the worlds confusion after publish. I recommend all world WGs do more reviews and discussion on their documents to get better reputation. Regards Abdussalam Baryun On 4/27/13, hammondjohn...@hushmail.com hammondjohn...@hushmail.com wrote: We are researchers from different parts of the world and conducted a study on the world’s biggest bogus computer science conference WORLDCOMP ( http://sites.google.com/site/worlddump1 ) organized by Prof. Hamid Arabnia from University of Georgia, USA. We submitted a fake paper to WORLDCOMP 2011 and again (the same paper with a modified title) to WORLDCOMP 2012. This paper had numerous fundamental mistakes. Sample statements from that paper include: (1). Binary logic is fuzzy logic and vice versa (2). Pascal developed fuzzy logic (3). Object oriented languages do not exhibit any polymorphism or inheritance (4). TCP and IP are synonyms and are part of OSI model (5). Distributed systems deal with only one computer (6). Laptop is an example for a super computer (7). Operating system is an example for computer hardware Also, our paper did not express any conceptual meaning. However, it was accepted both the times without any modifications (and without any reviews) and we were invited to submit the final paper and a payment of $500+ fee to present the paper. We decided to use the fee for better purposes than making Prof. Hamid Arabnia (Chairman of WORLDCOMP) rich. After that, we received few reminders from WORLDCOMP to pay the fee but we never responded. We MUST say that you should look at the above website if you have any thoughts to submit a paper to WORLDCOMP. DBLP and other indexing agencies have stopped indexing WORLDCOMP’s proceedings since 2011 due to its fakeness. See http://www.informatik.uni-trier.de/~ley/db/conf/icai/index.html for of one of the conferences of WORLDCOMP and notice that there is no listing after 2010. See Section 2 of http://sites.google.com/site/dumpconf for comments from well-known researchers about WORLDCOMP. The status of your WORLDCOMP papers can be changed from scientific to other (i.e., junk or non-technical) at any time. Better not to have a paper than having it in WORLDCOMP and spoil the resume and peace of mind forever! Our study revealed that WORLDCOMP is a money making business, using University of Georgia mask, for Prof. Hamid Arabnia. He is throwing out a small chunk of that money (around 20 dollars per paper published in WORLDCOMP’s proceedings) to his puppet (Mr. Ashu Solo or A.M.G. Solo) who publicizes WORLDCOMP and also defends it at various forums, using fake/anonymous names. The puppet uses fake names and defames other conferences to divert traffic to WORLDCOMP. He also makes anonymous phone calls and tries to threaten the critiques of WORLDCOMP (See Item 7 of Section 5 of above website). That is, the puppet does all his best to get a maximum number of papers published at WORLDCOMP to get more money into his (and Prof. Hamid Arabnia’s) pockets. Monte Carlo Resort (the venue of WORLDCOMP for more than 10 years, until 2012) has refused to provide the venue for WORLDCOMP’13 because of the fears of their image being tarnished due to WORLDCOMP’s fraudulent activities. That is why WORLDCOMP’13 is taking place at a different resort. WORLDCOMP will not be held after 2013. The draft paper submission deadline is over but still there are no committee members, no reviewers, and there is no conference Chairman. The only contact details available on WORLDCOMP’s website is just an email address! Let us make a direct request to Prof. Hamid arabnia: publish all reviews for all the papers (after blocking identifiable details) since 2000 conference. Reveal the names and
RE: [Tools-discuss] Last Call: draft-sheffer-running-code-04.txt (Improving Awareness of Running Code: the Implementation Status Section) to Experimental RFC
Hi Fred, I'm in complete agreement with you, but... :-) Before investing in a common set of tools to archive implementation information, I wanted to see whether there was *any* intention to make that information available. Thus, this is a baby-step towards the end result that you and I wold like to see. If, after our 18 month experiment, it turns out that no-one wants to record implementation information, we will know where we stand (or sit). OTOH, if there is good support for the idea, we can move to the next stage. Adrian -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Fred Baker (fred) Sent: 26 April 2013 17:08 To: Yaron Sheffer Cc: ietf@ietf.org; tools-disc...@ietf.org Discussion Subject: Re: [Tools-discuss] Last Call: draft-sheffer-running-code-04.txt (Improving Awareness of Running Code: the Implementation Status Section) to Experimental RFC On Apr 26, 2013, at 2:12 AM, Yaron Sheffer yaronf.i...@gmail.com wrote: - There should be long-term commitment to maintain the data. I think we simply don't have such processes in place, and personally I don't want to even try to deal with this problem. I suspect that we'd have to eventually use paid help if we are serious about keeping the information current, and I don't even think it would be worth the cost. Understood. That said, we already have working group wikis and errata. I don't want to trivialize the investment, but it seems like we have at least part of the infrastructure already. I'm asking what will be the best for IETF discussion and for maintenance of the information. I suspect it's something we can do if we choose to.=
RE: Last Call: draft-sheffer-running-code-04.txt (Improving Awareness of Running Code: the Implementation Status Section) to Experimental RFC
Hi AB, Thanks for your review. IMHO, we should not request to delete this proposed section, but it can be shifted to the Appendix section when published. Removing the section is like doing some work in IETF and then destroying it, future reviewers/implementers may not know why it was accepted to publish or be implemented. If I read a document from the past/present I would like to know its usefulness to increase my acceptance. There are two points related to this. The first is that the intent of the information is to enable the WG/community/IESG make a better assessment of the maturity and stability of the specification while advancing it through WG last call to RFC publication. Thus, once publication has been agreed, the information has served its purpose and can be dropped. The second point is that the information is likely to become obsolete very quickly. So, while there *is* marginal value in retaining the information that was true at the time of publication of an RFC, it is unclear that it provides great value. If the authors/WG consider that a living record of implementation of RFCs is valuable, if would be better to move this to a wiki. That, however, is beyond the scope of our I-D. I-D Introduction Some of them may never get implemented. ABamend Some of them may never get implemented or used. We implement a specification for a use case or to be used within another specification, some specification may have available to use another but never does use the other (was that a waste of running code, or may that be used by an attacking specification). I take your point, although I think it is rare for people to implement code without intending to execute it. I-D Section 2 AB I will add points: o the date of implementation. o the reason for implementation, or use-case targets. Would be useful information if people are willing to state it. ABQuest Why before security consideration? I recommend it to be after all sections, because implementors consider that security section within their work and may refer to it. Funny! Got to put the section somewhere. My preference is for it to be in the same place in all documents. Have had several responses suggesting different places to put the section. I can't get excited about where it should go. Yaron and I will discuss moving it. Section 3 AB Add the WG may replace it into a historical document that can be refered to by the current concerned WG document, Do you mean a historical RFC? I suppose this option is open to the WG if they want to go that way. for the reasons stated above, I would think that a poor idea. Section 5.1 18 Months AB The duration is not understood if it is maximum or minimum requirement. Please provide the requirement language to be clear. (I don't know from where the 18 came from, I like to specifying *three IETF WG meeting* presentations/discussions of such implementations. If you don't present/discuss the implementation inside IETF then how do we document such work/activity? This is the period during which the authors will conduct the experiment. At the end of this period the authors will report to the community. Why 18 months? Because that is what we think feels right given how long it takes to advance I-Ds. Should implementation status be presented at IETF meetings? That is entirely up to the WGs and the individuals involved. I am entirely uninterested in sitting through marketing presentations at IETF meetings. I have no objection to seeing a slide that reports on the current implementations status per the latest revision of an I-D - but I can't understand why people wouldn't just read the I-D to find out this information. ABComment in one WG it was said that some companies don't want to discuss their implementations or results. Is it strange to *use* the IETF specification and not report back to it for future progress of such document? Such is the world of business. Adrian
RE: Gen-ART LC review of draft-ietf-netmod-interfaces-cfg-10
Martin, Thanks for the response. I am OK with your responses to the nits. As for the comment on location I think I understand but what got me thinking was the examples. In E.1 An operator can configure a new interface by sending an edit-config containing: interface nc:operation=create namefastethernet-1/0/name /interface When the server processes this request, it will set the leaf type to ethernetCsmacd and location to 1/0. Thus, if the client performs a get-config right after the edit-config above, it will get: interface namefastethernet-1/0/name typeethernetCsmacd/type location1/0/location /interface I can see how the linkage between the location and name is done. I am not sure how the operator knows from the response what is the physical location without knowing the device type and manufacturer but at least the linkage is there and this is why I thought of it more as a logical device and not physical one. When looking at E2.2 example An operator can configure a new interface by sending an edit-config containing: interface nc:operation=create nameacme-interface/name typeethernetCsmacd/type location1/0/location /interface Here the operator need to know the device to configure a specific interface and know how many interface exist and how they are named. So you assume that for this case this is known to the configuration. Roni -Original Message- From: Martin Bjorklund [mailto:m...@tail-f.com] Sent: 28 April, 2013 12:50 PM To: ron.even@gmail.com Cc: draft-ietf-netmod-interfaces-cfg@tools.ietf.org; ietf@ietf.org; gen-...@ietf.org Subject: Re: Gen-ART LC review of draft-ietf-netmod-interfaces-cfg-10 Hi, Thank you for your review. Comments inline. Roni Even ron.even@gmail.com wrote: I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-netmod-interfaces-cfg-10 Reviewer: Roni Even Review Date:2013-4-28 IETF LC End Date: 2013-5-3 IESG Telechat date: 2013-5-16 Summary: This draft is almost ready for publication as Standard track RFC. Major issues: Minor issues: 1. I had some problem understanding the location leaf. Section 3.2 has it as a string and says that The device uses the location string to identify the physical or logical entity that the configuration applies to. I am not sure how you identify physical location having no definition of the mapping. The sentence just before the quoted one above says: The format of this string is device- and type-dependent. and then the text says: How a client can learn which types and locations are present on a certain device is outside the scope of this document. So the exact procedure is currently left to the vendors, but may be standardized in a future document (if possible...) I saw the examples in Appendix E and it looked more to me as logical mapping but not physical since it attaches a name to something in the device but I am not clear how you know what it is physically in the device. If the name 0-n or n/m are real physical entities, I think that it should be specified some place. Nits/editorial comments: 1.In the introduction section maybe add to the first sentence a reference to RFC6244 with some text. Ok, this probably makes sense. I will check w/ the WG and other documents. 2.In section 2 are the must and should used as described in RFC2119, if yes need capital letters Seciton 2 is more of a background, non-normative section. It lists some of the design objectives. 3.In section 3.1 It is optional in the data model, but if the type represents a physical interface, it is mandatory, suggest having RFC2119 language It is OPTIONAL in the data model, but if the type represents a physical interface, it is MUST be specified I think the first one should not be OPTIONAL, but the second one is correct. So I suggest this: It is defined as being optional in the data model, but if the type represents a physical interface, it MUST be specified. /martin
RE: [Tools-discuss] Last Call: draft-sheffer-running-code-04.txt (Improving Awareness of Running Code: the Implementation Status Section) to Experimental RFC
--On Sunday, April 28, 2013 12:22 +0100 Adrian Farrel adr...@olddog.co.uk wrote: Hi John, Seems consistent with what is in the I-D at the moment. See section 3. Thus, those who want to record the info in the I-D can do that, while those who want to go straight to a wiki can do that (although we ask that the I-D has a pointer to the wiki). Indeed. I was trying to make that point in a different way. To be more explicit, I think the I-D is fine, precisely because it allows some reasonable flexibility about that sort of option. I'd encourage the experimental evaluation process to compare those two options in practice (e.g., by including statistics about which method is used in the Summary Report (Section 5.2) and commenting on relative utility if there is anything to say). But there is nothing in the I-D that would prevent that and I'm not convinced that more specifics in this I-D would be worth the trouble. john
Re: Last Call: draft-sheffer-running-code-04.txt (Improving Awareness of Running Code: the Implementation Status Section) to Experimental RFC
Hi Dave, Thank you for your thorough review. While I accept many of your comments, I must say I disagree with you on a few points, which together go to the core of our motivation in writing this document. Thank you for helping me clarify these points to myself :-) - Our goal is much *less* ambitious than defining a framework for documenting implementations for long-term protocol projects. Our primary goal is to aid working group members in making informed decisions about the quality of specifications. I believe this narrow focus is much more realistic. - As a result of the above: 1. We define the information as pre-RFC only; 2. The main medium is the I-D, as opposed to Web pages/wikis/CMS (although we see them as valid alternatives); 3. We focus on WG documents, as opposed to all IETF documents. - Despite the glowing counterexample of DKIM, it is rarely practical to maintain implementation status information, keeping it current for years (put bluntly, you need to pay someone to do that). The IETF certainly does not have the processes or mechanisms to do so. And we do not try to establish such processes here. Please see my detailed comments below. Thanks, Yaron On 2013-04-26 19:16, Dave Crocker wrote: Given this thread on the ietf list, I guess I should forward the following, which was done as a solicited Apps Area review for this draft: Original Message Subject: Review of: draft-sheffer-running-code Date: Wed, 24 Apr 2013 06:38:24 -0700 From: Dave Crocker dcroc...@gmail.com To: draft-sheffer-running-code@tools.ietf.org, apps-disc...@ietf.org, i...@ietf.org Howdy. I have been selected as the Applications Area Review Team reviewer for this draft (for background on apps-review, please see http://www.apps.ietf.org/content/applications-area-review-team). Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Review -- Title:Improving Awareness of Running Code: the Implementation Status Section I-D: draft-sheffer-running-code-04 Reviewer: D. Crocker Review Date: 24 April 2013 Summary: Given an organizational motto of Rough consensus and running code, implementation experience has a value built into the IETF's DNA. However formal IETF reliance on running code for specifications has been minimal, with its only universal occurrence being in consideration of advanced standards status; it is notably /not/ an organizational requirement for entry-level Proposed Standard status, if only for the very high barrier to publication this imposes on document versions that were intended to be preliminary. The current draft proposes an experiment to optionally include documentation of implementations as part of document development, prior to issuance of a specification as an RFC. Within the broader perspective of pre- and post-standardization efforts, it is quite common to document available implementations of a specification. (As a convenient example, see http://dkim.org/deploy.) In effect, the current proposal merely seeks to have a common IETF-based means of recording a type of information that industry has already frequently formulated. In their current form, the draft and the proposal seem likely to be useful. However, both could be improved. The draft includes some language and assertions that would benefit from being a bit more carefully written; questions, comments and suggestions are in the detailed comments below. The proposal itself would benefit from directly paying more attention to existing industry practice, which is implied by the alternatives section; that is, that implementation lists already happen and are maintained after IETF document processing. The proposal should do a better job of integrating this fact into its design. One approach could be a relatively simple document change, to distinguish between specifying the information to be reported, as distinct from the means of reporting it -- think of it as payload vs. mechanism... Specify them separately. Then define both how to incorporate the information directly and the form of an external citation to it; this would eliminate the document's section on 'alternatives' and treat the original and alternative methods as equal. d/ Detailed Comments: 1. Introduction Most IETF participants are familiar with the saying, rough consensus and running code [Tao], and can identify with its pragmatic approach. However, there are many examples of Internet-Drafts containing protocol specification that have gone through to publication as Proposed Standard RFCs without implementation. Some of them may never get implemented. The however implies that it is wrong or problematic for Proposed to be assigned to unimplemented protocols. It isn't. I suggest a softer tone, while still noting the relevantfact. Something like: It is not a
Re: [Tools-discuss] Last Call: draft-sheffer-running-code-04.txt (Improving Awareness of Running Code: the Implementation Status Section) to Experimental RFC
On 4/28/2013 8:03 AM, Yaron Sheffer wrote: Hi Dave, Thank you for your thorough review. While I accept many of your comments, I must say I disagree with you on a few points, which together go to the core of our motivation in writing this document. Thank you for helping me clarify these points to myself :-) - Our goal is much *less* ambitious than defining a framework for documenting implementations for long-term protocol projects. Our primary goal is to aid working group members in making informed decisions about the quality of specifications. Forgive me, but working group members seem like the /least/ interesting target audience, since it is already the most-informed group, by virtue of its direct activity over the course of developing the specification. The people who are most likely to benefit from pointers to implementation details are: 1. Reviewers, who want a sense of implementation history to 'season' their analysis; 2. IESG members, who are deciding whether to vote approval for the specification; and 3. Those considering adoption of the technology for use, such as other implementers and service operators. That said, what you propose certainly accommodates #1 and #2, without needing to agree on their being a target audience... [However the small discussion, farther down, about being better able to evaluate competing proposals, does provide an example of benefit /within/ the working group...] - As a result of the above: 1. We define the information as pre-RFC only; 2. The main medium is the I-D, as opposed to Web pages/wikis/CMS (although we see them as valid alternatives); 3. We focus on WG documents, as opposed to all IETF documents. Right. And here my suggestions were merely to clarify this earlier in the proposal document. - Despite the glowing counterexample of DKIM, it is rarely practical to maintain implementation status information, keeping it current for years (put bluntly, you need to pay someone to do that). Would that I'd been getting paid... But yeah,it takes continuing effort. (On the other hand, there isn't much on-going work, after initial bursts of development activity.) At any rate, rather than insisting that the list be external and on-going, my intention was to suggest designing it to comfortably /allow/ the wg to make the choice of either, gracefully, including an easy transition from one to the other. - - - - - existence of running code. It is up to the individual working groups to use this information as they see fit, but one result might be the preferential treatment of documents resulting in them being processed more rapidly. I think it won't be the working group that 'uses' the information, but rather IETF management and the broader community? For most documents, AFAIK, most work is done by the WG, and a lot less by the rest of the community. Hence the above. IETF Working groups do not create market demand and do not do develop or deployment. All of that is quite explicitly outside the scope of the IETF, and at industry-scale, they represent more aggregate effort than is put in by the IETF working group... The scope of the intended experiment is all Internet-Drafts whether Probably not all I-Ds, since they do not all contain implementable specifications. Sheffer FarrelExpires October 14, 2013[Page 3] Internet-DraftRunning Code April 2013 produced within IETF working groups, outside working groups but What I-Ds are produced by outside working groups? I can't tell who this refers to.It's probably just as well to remove the attempted case analysis for groups and just say that the scope is all specifications issued as I-Ds. In fact others have commented that we should exclude individual submissions for process reasons. Right. That suggests writing the scoping text a bit more tightly. o Participants are motivated to implement protocol proposals, which helps in discovering protocol flaws at an early stage. The psychological premise seems to be that getting cited in this list will somehow serve as an incentive to implementers. I can imagine that they'll like being listed, but find it extremely difficult to believe that it will affect whether they do the work; not that I think it's a deciding factor, but note that the ego value is further reduced by the information's being ephemeral, since it it removed prior to RFC publication! Actually not (subtly so). The premise is making this information public and an explicit part of WG deliberations will incentivize implementations (i.e. not the ego factor at all). The statements you are making about incentives to implementers really are in terms of their ego, since you have not stated any other benefit that will accrue to /them/. There will be benefits to the community at large, but the question in this section of text is what the motivation of the implementer will be. o
Re: IETF Diversity Question on Berlin Registration?
Hi Tom, On Apr 19, 2013, at 6:03 AM, t.p. daedu...@btconnect.com wrote: If we required the IETF to reflect the diversity of people who are, e.g., IT network professionals, then the IETF would fall apart for lack of ability. […] If the ADs of the IETF have to represent the diversity of the world - which could in extremes.. Has anyone even suggested that IESG should reflect the diversity of these groups? Where is this coming from? You are putting up strawmen, so that you can tear them down… The question that people are asking is why the diversity of the IETF leadership doesn't reflect the diversity of _the IETF_. There is no inherent reason why 40+-year-old, white, western males who work at large networking equipment vendors are inherently more capable of serving on the IESG than people from other groups within the IETF, and there would be _considerable internal benefit_ to having an IESG that was more diverse, because diverse groups make better decisions and better represent the needs of the whole organization. Therefore, if there is something about our culture, our structure, our selection process, or the way we run our meetings that is causing us to predominantly select our leadership from a restricted group, we would have _more capable_ and _better_ leadership if we could find a way to broaden that pool. _That_ is what this discussion is about. This is not an effort to meet some externally imposed notion of diversity. Margaret
Re: IETF Diversity Question on Berlin Registration?
On 04/29/2013 07:53 AM, Margaret Wasserman wrote: Hi Tom, On Apr 19, 2013, at 6:03 AM, t.p. daedu...@btconnect.com wrote: If we required the IETF to reflect the diversity of people who are, e.g., IT network professionals, then the IETF would fall apart for lack of ability. […] If the ADs of the IETF have to represent the diversity of the world - which could in extremes.. Has anyone even suggested that IESG should reflect the diversity of these groups? Where is this coming from? You are putting up strawmen, so that you can tear them down… The question that people are asking is why the diversity of the IETF leadership doesn't reflect the diversity of _the IETF_. There is no inherent reason why 40+-year-old, white, western males who work at large networking equipment vendors are inherently more capable of serving on the IESG than people from other groups within the IETF, and there would be _considerable internal benefit_ to having an IESG that was more diverse, because diverse groups make better decisions and better represent the needs of the whole organization. Therefore, if there is something about our culture, our structure, our selection process, or the way we run our meetings that is causing us to predominantly select our leadership from a restricted group, we would have _more capable_ and _better_ leadership if we could find a way to broaden that pool. It seems like everybody in the IETF is already in that pool. After all, any participant can self-nominate for an AD position; how can the pool get any bigger? _That_ is what this discussion is about. Really? It appeared to me that the discussion arose because some people were unhappy about the makeup of the IESG, not the selection pool. However, if what you're saying is true, that's great: since the selection pool is already universally inclusive, problem solved we can turn our seemingly limitless capacity for bickering to other purposes ;-) . This is not an effort to meet some externally imposed notion of diversity. Margaret
What's a reasonable and non-discriminatory patent license?
The Patently-O blog has a new guest post by Jorge Contreras, who among other things is the IETF's lawyer, on a recent court decision about how to determine what's an appropriate RAND royalty rate for standard-essential patents. The patents and standards in question aren't from the IETF (they're ITU H.264 and IEEE 801.11) but the article is highly relevant to the patent issues that crop up here. Jorge writes well and it's quite readable. http://www.patentlyo.com/patent/2013/04/so-thats-what-rand-means-a-brief-report-on-the-findings-of-fact-and-conclusions-of-law-in-microsoft-v-motorola.html -- Regards, John Levine, jo...@iecc.com, Primary Perpetrator of The Internet for Dummies, Please consider the environment before reading this e-mail. http://jl.ly
Re: IETF Diversity Question on Berlin Registration?
At 08:53 PM 4/28/2013, Margaret Wasserman wrote: The question that people are asking is why the diversity of the IETF leadership doesn't reflect the diversity of _the IETF_. Let's consider for a moment that this may not actually be the correct question. Instead, consider Why the diversity of the IETF leadership doesn't reflect the diversity of the set of the IETF WG chairs? I believe this is a more representative candidate population for the IAB and IESG. By my count (using the WG chairs picture page), there are 202 current working group chairs. Of these 15 are female - or 7.4% of the population [It would be more reliable to do this for any WG chair in the last 5-10 years, but the above was readily available and I think provides at least the basis for discussion. Anticipating the argument, I would assume for the sake of discussion a fairly similar percentage of ex-working group chairs per gender unless there is evidence to the contrary] There are 14 (current area directors plus the chair) members of the IESG, of which none are currently female. There are 12 current IAB members of which 1 member is female. Assuming perfect distribution, that would suggest that 14 * (15/202) or 1.03 IESG members should be female. Assuming perfect distribution, that would suggest that 12 * (15/202) or .89 IAB members should be female. Assuming perfect distribution, that would suggest that 26 * (15/202) or 1.93 IAB + IESG members should be female. And pretending for a moment that picks for the IAB and IESG are completely random from the candidate set of Working group chairs, the binomial distribution for 7.4% for 27 positions is: 0 - 12.5%, 1 - 27.0%, 2 - 28.1%, 3 or more - 32.5%. (e.g. about 40% of the time, the IAB and IESG combined will have 0 or 1 female members). for 7.4% for 15 positions (IESG) is: 0 - 31.4%, 1 - 37.8%, 2 - 21.2%, 3 or more - 9.5% for 7.4% for 12 positions (IAB) is: 0 - 39.6%, 1 - 38.1%, 2 - 16.8%, 3 or more - 5.4% But the actual one you should consider is 7.4% for 14 positions (annual replacement): 0 - 34%, 1 - 38.1%, 2 - 19.9%, 3 or more - 8%. This last one says that for any given nomcom selection, assuming strict random selection, 72% of the time 0 or 1 females will be selected across both the IAB and IESG. You should use this one as the actual compositions of the IAB/IESG are the sum of all the nomcom actions that have happened before. There are statistical tests to determine whether there is a statistically significant difference in populations, but my admittedly ancient memories of statistics suggest that the population size of the IAB/IESG is too small for a statistically valid comparison with either the WG chair population or the IETF population. Of course, the nomcom doesn't select and the confirming bodies do not confirm based on a roll of the dice. But looking at this analysis, it's unclear - for this one axis of gender - that the question why the diversity of the IETF leadership does not reflect the diversity of the set of IETF WG chairs has a more correct answer than the luck of the draw. My base premise may be incorrect: That you need to have been a WG chair prior to service as an IAB or IESG member. I hope it isn't as I think this level of expertise is useful for success in these bodies. Assuming it is correct, then the next question is whether or not there is a significant difference in percentage of female attendees vs percentage of female working group chairs and is there a root cause for that difference that the IETF can address in a useful manner. Mike
Re: last call comments for draft-ietf-6man-stable-privacy-addresses-06
Hi - From: Michael Richardson mcr+i...@sandelman.ca To: ietf ietf@ietf.org; Andrew McGregor andrewm...@gmail.com Cc: Christian Huitema huit...@microsoft.com; SM s...@resistor.net Sent: Friday, April 26, 2013 5:47 AM Subject: Re: last call comments for draft-ietf-6man-stable-privacy-addresses-06 ... I think that non-contiguous ifindexes are a pain in the ass (based upon my understanding of enumeration of interfaces in the interface MIB), but are they essentially forbidden? Having holes would make it easier to keep things consistent. This is exactly what RFC 2863 (The Interfaces Group MIB) specifies. Non-contiguous ifIndex values are permitted. This issue was considered at some length in the development of RFC 2863. Section 3.1.5 explains in detail why the semantics of ifIndex were changed (from their original MIB-II definition) to permit holes, while the semantics of ifNumber were left untouched. Randy
Re: [Tools-discuss] Last Call: draft-sheffer-running-code-04.txt (Improving Awareness of Running Code: the Implementation Status Section) to Experimental RFC
On 4/28/13, Yaron Sheffer yaronf.i...@gmail.com wrote: Hi Dave, Thank you for your thorough review. While I accept many of your comments, I must say I disagree with you on a few points, which together go to the core of our motivation in writing this document. Thank you for helping me clarify these points to myself :-) - Our goal is much *less* ambitious than defining a framework for documenting implementations for long-term protocol projects. Our primary goal is to aid working group members in making informed decisions about the quality of specifications. I believe this narrow focus is much more realistic. Was this goal/point mentioned in the I-D if not, it will be nice to clarify this point to future readers, - As a result of the above: 1. We define the information as pre-RFC only; 2. The main medium is the I-D, as opposed to Web pages/wikis/CMS (although we see them as valid alternatives); 3. We focus on WG documents, as opposed to all IETF documents. If not mentioned in I-D, please clarify this point in the I-D,
Re: IETF Diversity Question on Berlin Registration?
On 4/28/2013 9:05 PM, Michael StJohns wrote: Let's consider for a moment that this may not actually be the correct question. Instead, consider Why the diversity of the IETF leadership doesn't reflect the diversity of the set of the IETF WG chairs? I believe this is a more representative candidate population for the IAB and IESG. Except that the IESG members select the wg chairs, which makes your baseline stastistic suspect; it's too easy for all sorts of biasing factors to sway the allocation of wg chair positions. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
RE: IETF Diversity Question on Berlin Registration?
Except that the IESG members select the wg chairs, which makes your baseline stastistic suspect; it's too easy for all sorts of biasing factors to sway the allocation of wg chair positions. Mike actually mentioned that. Let's assume a simplified curriculum of participant - author/editor - WG chair - IESG, which more or less reflects increasing seniority in the IETF. We may suspect that there is bias that, at each step, privileges some candidates over others. However, the mechanisms are different at each step. Self-selection, selection by WG chair, selection by the nom com. It makes sense to assess the filtering effect of each step independently, and in particular to assess the nomcom by comparing the pool of WG chairs to the selected nominees. -- Christian Huitema
Re: IETF Diversity Question on Berlin Registration?
On 4/28/2013 10:52 PM, Christian Huitema wrote: Except that the IESG members select the wg chairs, which makes your baseline stastistic suspect; it's too easy for all sorts of biasing factors to sway the allocation of wg chair positions. Mike actually mentioned that. Let's assume a simplified curriculum of participant - author/editor - WG chair - IESG, which more or less reflects increasing seniority in the IETF. We may suspect that there is bias that, at each step, privileges some candidates over others. However, the mechanisms are different at each step. Exactly. Complicated processes, needing high quality data that gets complicated analysis, that we aren't well-enough trained to do well and aren't going to be doing. All of which is why we should limit our attempts to do numerical analysis for this topic, and worry far more about the basics, including such things as interaction (in)sensitivities, group tone and style, and observable misbehaviors, all of which are likely to produce biasing results. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
