Re: Less Corporate Diversity
On Fri, Mar 22, 2013 at 1:28 AM, Eric Burger ebur...@standardstrack.comwrote: Quite the contrary. I am interpreting a few of the 'diversity' posts as saying the IETF has fewer companies participating and much fewer smaller companies participating. And I am interpreting those posts as implying some nefarious plot on the part of large, Western, White-European-Male-Dominated companies to make it that way. I was just positing that the IETF might be reflective of the networking industry as a whole. My thesis, not at all proven and one I am not married to, is there are fewer *companies* out there. With fewer companies, we should not be surprised there are fewer companies participating. On the big side, a ton of major players either merged or left the business. On the small side, a bunch of companies either got acquired or went bankrupt. It's not a nefarious plot; all the meetings I've had with the rest of the Western White European Male Cabal haven't discussed the IETF at all, they're mostly on about the outrageous cost of fuel, these days. Quite honestly I'm thinking of leaving. But I suspect the idea that there are fewer companies when the word startup seems to automatically imply something Internet related is wrong. There's plenty of small companies, but engagement in the IETF is either irrelevant - because the IETF has slipped lower down the stack - or too expensive - because when you have fewer than 10 people in your organization, losing one engineer for half a day a week of IETF activity represents 1%, whereas if you've a company of even just a thousand, losing an engineer to the IESG full time is an order of magnitude less. That's not considering the cost as an issue, which it undoubtedly is for a small company, especially those outside the US for whom the travel costs are higher. I think the IETF leadership could solve the stack problem by being more proactive about encouraging standardization work to be brought into the IETF - I think having WebFinger here, for example, is very useful at making the IETF relevant to the startup audience, as it were, and there are several other of these small, high-stack protocols that would benefit from being worked on in the IETF and would benefit the IETF too. Dave.
Re: Less Corporate Diversity
On Mar 22, 2013, at 5:47 AM, Dave Cridland d...@cridland.net wrote: But I suspect the idea that there are fewer companies when the word startup seems to automatically imply something Internet related is wrong. There's plenty of small companies, but engagement in the IETF is either irrelevant - because the IETF has slipped lower down the stack - or too expensive - because when you have fewer than 10 people in your organization, losing one engineer for half a day a week of IETF activity represents 1%, whereas if you've a company of even just a thousand, losing an engineer to the IESG full time is an order of magnitude less. That's not considering the cost as an issue, which it undoubtedly is for a small company, especially those outside the US for whom the travel costs are higher. These sorts of arguments would make more sense if it weren't the case that the candidate pool published by the nomcom is more diverse (in this and other ways) than the people who are selected by the nomcom. Granted, it may be that the list of _qualified_ candidates is less diverse than the set of all people who are willing to run. But, if so, that isn't because there aren't companies who are willing/able to support candidates... Margaret
Architecture (was: Re: Less Corporate Diversity)
On Mar 21, 2013, at 8:58 AM, Keith Moore mo...@network-heretics.com wrote: ... Another result is that the Internet architecture has gone to hell, and we're now spending a huge amount of effort building kludges to fix the problems associated with other kludges and the new kludges will almost certainly create more problems resulting in a need for more kludges later. Keith - While I won't argue with the symptoms you describe, I'm not sure I'd attribute it to lack of diversity. Both wildly diverse and relatively homogeneous communities can still bifurcate on multiple approaches to solving any given problem, and if that happens repeatedly and at multiple layers, then we inevitably end up with a bit of a mess... What you are seeing is more likely the result of applying relatively few architectural principles in weeding out possible solutions, i.e. more of the let a thousand protocols bloom and the market will decide approach generally taken when establishing working groups and deliverables. FYI, /John Disclaimer: My views alone. No new protocols or working groups were created by this email thread... (yet).
Re: Please review draft-housley-rfc2050bis-00.txt
Elwyn: Two points: Rereading things again, I have another suggestion; 4) Split the Goals of the Internet registry system out of the Introduction. The Intro starts out talking about the document, its goals, and what is in scope and out of scope of the document. Then transitions to talking about the goals of the Internet registry system. I think the goals of the Internet registry system should be a separate section from the Introduction. And, the Introduction should be expanded to better describe the purpose of the document. I agree fully with this comment. The first para of s1 needs a rewrite and a little expansion to match up with the abstract to form a proper intro. The goals do belong in a separate section Okay. I'll tackle that for the next version. Also regarding the first para of s4: This contains some woolly hand-waving weasel words at the end: Over the years, the Internet Numbers Registry System has developed mechanisms by which the structures, policies, and processes of the Internet Numbers Registry System itself can evolve to meet the changing demands of the global Internet community. Further evolution of the Internet Numbers Registry System is expected to occur in an open, transparent, and broad multi-stakeholder manner. ^^^ Who are these stakeholders? Is this (just) the organisations named in the document (I think that would be ICANN/IANA, IETF, *IRs - a large number!) or is the community to be consulted? and governments? So do we have a view as to how all these people are to be informed that some evolution is needed? How would you describe the bottoms-up policy development process used by the RIRs? And, when all of them agree, the adoption of a global policy. Russ
Re: Please review draft-housley-rfc2050bis-00.txt
On Mar 20, 2013, at 6:04 PM, SM wrote: At 12:43 20-03-2013, Elwyn Davies wrote: This contains some woolly hand-waving weasel words at the end: I looked up the meaning of weasel words and found the following: words and phrases aimed at creating an impression that something specific and meaningful has been said, when in fact only a vague or ambiguous claim, or even a refutation has been communicated. I might as well comment quickly about draft-housley-rfc2050bis-00. The draft is a good effort but it might need more work in my humble opinion. The intended status is Informational. Is there a reason for that? RFC 2050 contains rules that are superseded by RIR policies. Why does the document obsolete RFC 2050? There is no explanation for that in the Abstract or the Introduction section. This document replaces RFC 2050. Since the publication of RFC 2050, the Internet Numbers Registry System has changed significantly. This document describes the present Internet Numbers Registry System. In Section 2: The Internet Assigned Numbers Authority (IANA) is the traditional name for the technical team making and publishing the assignments of Internet protocol technical parameters, including Internet Protocol (IP) address space. Is there a reference for that? RFC 2860 seems to be a fine reference. We could find others, but this seems to be good enough. As a result of a Memorandum of Understanding (MOU)[RFC2860] between the IETF, IAB, and ICANN, the technical work of the Internet Assigned Numbers Authority (IANA) is now performed by ICANN. According to RFC 2860: The memo is exclusively to define the technical work to be carried out by the Internet Assigned Numbers Authority on behalf of the Internet Engineering Task Force and the Internet Research Task Force. That does not match the as a result text. Today, IANA administers IP address space and AS numbers according to global number resource policies as developed per the agreement between ICANN and the Regional Internet Registries [ASOMOU] and documented in [ICANNv4], [ICANNv6], and [ICANNASN]. I don't see what the above has to do with structure (see section title). The authors will try to improve the wording. The discussion of IANA should probably say that IANA represents to top of the IP address and AS number allocation hierarchies. In Section 3: Reverse DNS: In situations where reverse DNS was used, the policies and practices of the Internet Numbers Registry System have included consideration of the technical and operational requirements posed by reverse DNS zone delegation [RFC3172]. According to RFC 5855: The choice of operators for all nameservers concerned is beyond the scope of this document and is an IANA function that falls under the scope of Section 4 of the MoU between the IETF and ICANN [RFC2860]. Maybe referencing RFC 5855 would be better. It may be easier not to say anything about reverse DNS. Thanks. Public WHOIS: The policies and practices of the Internet Numbers Registry System have included consideration of the technical and operational requirements for supporting WHOIS services [RFC3013]. The specification for Whois is RFC 3912. I vaguely recall that the policy text in the previous specification was viewed as problematic by the IETF. Thanks. Per the delineation of responsibility for Internet address policy issues specified in the IETF/IAB/ICANN MOU [RFC2860], discussions regarding the evolution of the Internet Numbers Registry System structure, policy, and processes are to take place within the ICANN framework and will respect ICANN's core values [ICANNBL]. These core values encourage broad, informed participation reflecting the functional, geographic, and cultural diversity of the Internet at all levels of policy development and decision-making, as well as the delegation of coordination functions and recognition of the policy roles of other responsible entities that reflect the interests of affected parties. The discussions regarding Internet Numbers Registry evolution must also continue to consider the overall Internet address architecture and technical goals referenced in this document. Could someone please translate the above in plain English? What's the IETF angle in all that? This points to the policy structure that replaces the rules that were in RFC 2050. What action is required from IANA in Section 7? No actions at this time. Why should I read RFC 6484 to understand draft-housley-rfc2050bis-00? It should be informative. Russ
Re: Please review draft-housley-rfc2050bis-00.txt
Hi Russ, At 08:43 22-03-2013, Russ Housley wrote: RFC 2050 contains rules that are superseded by RIR policies. That doesn't explain the label. :-) This document replaces RFC 2050. Since the publication of RFC 2050, the Internet Numbers Registry System has changed significantly. This document describes the present Internet Numbers Registry System. I suggest adding text, for example, what is mentioned above. RFC 2860 seems to be a fine reference. We could find others, but this seems to be good enough. Ok. The authors will try to improve the wording. The discussion of IANA should probably say that IANA represents to top of the IP address and AS number allocation hierarchies. There is already text in the first paragraph of Section 2. I suggest leaving it to that. This points to the policy structure that replaces the rules that were in RFC 2050. John Curran responded to this. The current text is not clear. If you would like to remove policy text it may be better not to get into policy text. No actions at this time. I suggest removing the IANA Considerations Section. It should be informative. I don't see how it would be referenced in the draft then. I suggest removing that reference. Regards, -sm
Re: Architecture
On 03/22/2013 09:50 AM, John Curran wrote: On Mar 21, 2013, at 8:58 AM, Keith Moore mo...@network-heretics.com wrote: ... Another result is that the Internet architecture has gone to hell, and we're now spending a huge amount of effort building kludges to fix the problems associated with other kludges and the new kludges will almost certainly create more problems resulting in a need for more kludges later. Keith - While I won't argue with the symptoms you describe, I'm not sure I'd attribute it to lack of diversity. Both wildly diverse and relatively homogeneous communities can still bifurcate on multiple approaches to solving any given problem, and if that happens repeatedly and at multiple layers, then we inevitably end up with a bit of a mess... What you are seeing is more likely the result of applying relatively few architectural principles in weeding out possible solutions, i.e. more of the let a thousand protocols bloom and the market will decide approach generally taken when establishing working groups and deliverables. I don't think we're in disagreement. I think that more diversity in IETF would help minimize the risk that some interests were shortchanged, but I certainly agree that another factor is a lack of understanding of, and respect for, the effect of certain changes on the Internet architecture. Have we even tried to identify and advertise those architectural principles since the early days? Keith
Re: Architecture
On Mar 22, 2013, at 2:49 PM, Keith Moore mo...@network-heretics.com wrote: I don't think we're in disagreement. I think that more diversity in IETF would help minimize the risk that some interests were shortchanged, but I certainly agree that another factor is a lack of understanding of, and respect for, the effect of certain changes on the Internet architecture. Interesting... that could be the case. Have we even tried to identify and advertise those architectural principles since the early days? It may no longer be achievable, as pressure from vendors for new features and functionality drives new protocols and protocol additions, and while saying no sounds good in theory, the reality is that it probably doesn't really prevent the efforts, as much as cause them to be done as via private vendor=specific efforts... /John
Re: Less Corporate Diversity
On 3/22/2013 4:43 AM, Margaret Wasserman wrote: ... Granted, it may be that the list of _qualified_ candidates is less diverse than the set of all people who are willing to run. But, if so, that isn't because there aren't companies who are willing/able to ^ support candidates.. If you define diversity as many different *companies*, sure. There are organizations besides companies that used to participate in the IETF more. Joe
Re: Architecture
On 03/22/2013 03:03 PM, John Curran wrote: On Mar 22, 2013, at 2:49 PM, Keith Moore mo...@network-heretics.com wrote: I don't think we're in disagreement. I think that more diversity in IETF would help minimize the risk that some interests were shortchanged, but I certainly agree that another factor is a lack of understanding of, and respect for, the effect of certain changes on the Internet architecture. Interesting... that could be the case. Have we even tried to identify and advertise those architectural principles since the early days? It may no longer be achievable, as pressure from vendors for new features and functionality drives new protocols and protocol additions, and while saying no sounds good in theory, the reality is that it probably doesn't really prevent the efforts, as much as cause them to be done as via private vendor=specific efforts... What's necessary, I think, is to respond to pressure for new features and functionality differently. Rather than saying yes or no, say we have noticed that the existing architecture fails to meet needs X, Y, and Z; and we propose to change the architecture in such a way to accommodate those needs while still safeguarding other important features or interests Keith
Re: Less Corporate Diversity
Melinda Shore wrote: Martin Rex wrote: As I understand and see it, the IESG is running IETF processes, is mentoring IETF processes (towards WG Chairs, BOFs, individuals with complaints/appeals), and is trying to keep an eye on the overall architecture, and put togethe the pieces from reviews they obtain from their trusted reviewers, such as directorates. They also gatekeep the work. If they don't believe that something is a problem, whether it because it's outside of the experience or expertise, or it really isn't a problem, it doesn't get chartered, it doesn't get sponsored, and it doesn't get published. If everybody serving that gatekeeper function comes from a similar background (western white guy working for a large manufacturer) it's going to tend to create certain biases in the work that's taken on. To me, this gatekeeping looks more like an act of self-defence. When I started going to IETFs in July 1995 (33rd IETF in Stockholm), there were only 2-hour slots and a number of WGs were using 2 slots. Over the years, the number of WGs BOFs grew, and some slots were split in two, fewer and fewer WGs meeted twice, and then additonal slots were added on friday, and it became more and more difficult to avoid conflicts (and for co-ADs to ensure that at least one of them could participate in WGs of their area). Chartering and running a WG has a significant process overhead, and requires (a) volunteers to do do the work and (b) volunteers with IETF process experience to drive the processes. Before allowing a new WG to start, ADs seem to make an assessment of whether there are sufficient volunteers of both kinds to do the work, whether there is sufficient expertise in the IETF to perform adequate review of the results and whether there is sufficient momentum in the effort (sufficiently large interest group, sufficiently strong desire) so that there is actually going to be results. What IETF participants often do to route around this (that is at least a common practice in the security area), is to set up WGs sufficiently broad that not only a few WG items are discussed, but also a number of individual submissions on the side, only some of which are officially adopted as WG work items. And WG charters may sometimes be several years out of date. One of the problems of long running WGs is, however, that they may slow down and kill new work due to diversity over the years. PKIX is in such a position. Over the years a huge number of documents were created, and fixing defects in existing documents is roadblock by personal pride (for the original documents, including their defects) and the fear of loosing face when implementations in the installed base are suddenly identified as being defective. The root cause of the many defects is vast feature bloat. The original design principle perfection is achieved not when there is nothing left to add, but when there is nothing left to remove does not apply to PKIX. And the same problem is slowly creeping into other protocols of the IETF security area as well. TLSv1.2 is also suffering from feature bloat and a few defects, and pride is likely to prevent dropping of the goofed SignatureAlgorithm extension. -Martin
Re: Less Corporate Diversity
On 3/22/13 6:17 PM, Martin Rex wrote: Before allowing a new WG to start, ADs seem to make an assessment of whether there are sufficient volunteers of both kinds to do the work, whether there is sufficient expertise in the IETF to perform adequate review of the results and whether there is sufficient momentum in the effort (sufficiently large interest group, sufficiently strong desire) so that there is actually going to be results. The value of the work, the likelihood of success, perceived need in the industry, and correctness are assessed. Sorry, Martin, but you're not describing how the IETF actually works. Melinda
Re: Less Corporate Diversity
On 03/23/2013 02:22 AM, Melinda Shore wrote: Sorry, Martin, but you're not describing how the IETF actually works. FWIW, seems to me you're describing one leg of the elephant each. From my experience I'd say you both actually have an appreciation of the overall elephant but that's not coming out in this kind of thread. S. PS: Martin does write more inflammatory text sometimes, but I think he knows and has previously ack'd that;-)
Re: Less Corporate Diversity
On 3/22/13 6:28 PM, Stephen Farrell wrote: FWIW, seems to me you're describing one leg of the elephant each. From my experience I'd say you both actually have an appreciation of the overall elephant but that's not coming out in this kind of thread. Well, maybe, but it seems to me that he's lost track of the discussion. My argument is that the IESG has a gatekeeping function in taking on new work, that's based (aside from resourcing) on a set of values, their view of what's needed in the industry, etc. With a uniform IESG membership you're not going to get a rather uniform view of the overall context for IETF work, you'll lose perspective, and consequently there's value to having members who aren't almost all from big manufacturers. I'm not sure what Martin's point is, to be honest. Melinda
Re: Less Corporate Diversity
On 21/03/13 1:33 PM, John C Klensin wrote: --On Wednesday, March 20, 2013 23:36 +0100 Jari Arkko jari.ar...@piuha.net wrote: I think it is mostly market forces and historical reasons, and the development of the IETF to focus on more particular core aspects of the Internet (like routing) as opposed to what the small shops might work on. I mostly agree. However, I see lots of activity in Apps and RAI, very little of which would seem to be core aspects of the Internet. Also, given the cost factor, the length of time it usually seems to take us to spin up a WG and get anything done is probably also a significant barrier: a small shop who could afford to send someone to a meeting or three might have neither the people-resources nor travel and meeting budget to commit to a few years of meetings. Hi John, I think that any small shop (whatever that means) would be put off if they sent someone to an IETF as it appears that it is dominated by the big vendors pushing their own agendas. Given that impression I imagine the small shop has better things to do with its resources. Mark.
Re: Less Corporate Diversity
Melinda Shore wrote: Stephen Farrell wrote: FWIW, seems to me you're describing one leg of the elephant each. From my experience I'd say you both actually have an appreciation of the overall elephant but that's not coming out in this kind of thread. Since I personally participated only IETFs 33rd through 43rd plus 48th, the picture of the elephant might be somewhat outdated. Back then, I had many fine lunches and dinners with WG chairs, security AD and other folks from the security area. Well, maybe, but it seems to me that he's lost track of the discussion. My argument is that the IESG has a gatekeeping function in taking on new work, that's based (aside from resourcing) on a set of values, their view of what's needed in the industry, etc. With a uniform IESG membership you're not going to get a rather uniform view of the overall context for IETF work, you'll lose perspective, and consequently there's value to having members who aren't almost all from big manufacturers. I'm not so sure I would still call it gatekeeping these days. To me, it looks more like trying to hold back the flood. In 1995 there were fewer WGs, only 2 hours slots at Meetings, and some WGs were regularly using two slots. Today, some ADs might want to start a new WG in their area only when they can make an exiting WG in their area conclude. So you might be running in a competition to the WG that is currently being done, rather being subject to only the IESGs free and unconstrained value judgement. -Martin
Re: Less Corporate Diversity
I would have to disagree with: On 3/22/2013 11:17 PM, Mark Prior wrote: ... Hi John, I think that any small shop (whatever that means) would be put off if they sent someone to an IETF as it appears that it is dominated by the big vendors pushing their own agendas. Given that impression I imagine the small shop has better things to do with its resources. Mark. While I work for a very large shop now, for most of my career I have worked for small or mid-size shops. Even startups. And all saw value in sending me to IETF meetings. Yours, Joel
Re: Less Corporate Diversity
Brian E Carpenter wrote: Martin Rex wrote: My impression of todays IESG role, in particular taking their balloting rules and their actual balloting results into account, is more of a confirming body of work that happened elsewhere (primarily in the IETF, typically in IETF WGs, but also individual or interest groups submissions from elsewhere, though the latter mostly for (re)publication as informational). IMHO, the IESG is not (and maybe never was?) a committee where _each_ member reviews _all_ of the work, where _each_ forms his very own opionion, and where all of them caste a VOTE at the end, so that the diversity within that committee would be vitally beneficial (to anything). I think you've misinterpreted the IESG procedures a bit. The definition of a NO OBJECTION ballot in the IESG ranges from I read it, and I have no problem with it to I listened to the discussion, and I have no problem. I don't think so. When I had a phone call with Russ Housley in early 2010, one of the things I said was that considering the amount of document that pass through the IESG, I would assume that not every AD was reading every document and that each AD might be reading only about 1/4 of them, and he replied that this could be near the real numbers. It's impossible to say objectively which of these extremes predominates, but when I was General AD, I tried to at least speed-read every draft, and studied the Gen-ART reviews carefully. Individual ADs vary in their habits according to workload, but my sense is that there is a strong sense of collective responsibility and definitely not a sense of rubber stamping. I do not think that the IESG is actively rubber stamping, and I know of a few past events where the IESG actively resisted to such attempts. However, the ballot process is made to err towards publication of a document. How often does the IESG *not* publish documents, and why? Considering the effort it took to convince IESG not to take an action / publish a document (IIRC draft-ietf-v6ops-6to4-to-historic-04.txt) then I'm much less convinced that having a ballot procedure that fails towards action/publication is such a good idea. -Martin
RE: Less Corporate Diversity
Joel, the small shops you worked for were in the US, right? Lloyd Wood http://sat-net.com/L.Wood/ From: ietf-boun...@ietf.org [ietf-boun...@ietf.org] On Behalf Of Joel M. Halpern [j...@joelhalpern.com] Sent: 23 March 2013 03:24 To: Mark Prior Cc: John C Klensin; ietf@ietf.org Discussion; Eric Burger Subject: Re: Less Corporate Diversity I would have to disagree with: On 3/22/2013 11:17 PM, Mark Prior wrote: ... Hi John, I think that any small shop (whatever that means) would be put off if they sent someone to an IETF as it appears that it is dominated by the big vendors pushing their own agendas. Given that impression I imagine the small shop has better things to do with its resources. Mark. While I work for a very large shop now, for most of my career I have worked for small or mid-size shops. Even startups. And all saw value in sending me to IETF meetings. Yours, Joel
RFC 6907 on Use Cases and Interpretations of Resource Public Key Infrastructure (RPKI) Objects for Issuers and Relying Parties
A new Request for Comments is now available in online RFC libraries. RFC 6907 Title: Use Cases and Interpretations of Resource Public Key Infrastructure (RPKI) Objects for Issuers and Relying Parties Author: T. Manderson, K. Sriram, R. White Status: Informational Stream: IETF Date: March 2013 Mailbox:terry.mander...@icann.org, ksri...@nist.gov, r...@riw.us Pages: 31 Characters: 66099 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-sidr-usecases-06.txt URL:http://www.rfc-editor.org/rfc/rfc6907.txt This document describes a number of use cases together with directions and interpretations for organizations and relying parties when creating or encountering Resource Public Key Infrastructure (RPKI) object scenarios in the public RPKI. All of these items are discussed here in relation to the Internet routing system. This document is a product of the Secure Inter-Domain Routing Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC
JOSE Working Group Interim Meeting April 29-30, 2013
JOSE WG Interim Details Dates/Times: 29-30 April 2013 (9:00 am - 5:00 pm MDT) Location: Cisco, 1899 Wynkoop Street, Suite 600, Denver, CO, USA Registration: Send jose co-chairs an email (only for capacity planning purposes as we have limited space) Remote Participation: via Webex Lodging: Individual responsibility. There appear to be several options in the $125 - $200 range within 1 mile of the meeting site.
