Re: [IETF] Issues in wider geographic participation
Randy, Warren, >> One (IMO) good idea that was mentioned recently (sorry, I cannot >> remember by whom, may have been Jim Martin) was for someone from the >> IETF to present a short summary of interesting work at NOG meetings. > > this has been done many times. imiho, it has not stirred up much useful > interaction unless the ietfer says something really st00pid. then it > gets amusing. I have found that generic "this is happening" informational is usually not so interesting. Whereas discussion on specific topics has been far more interesting… sessions that talk about some IETF WG technology, operator's problems in that area, and someone's experience in deploying the stuff are very interesting IMO. Jari
Re: Not Listening to the Ops Customer (was Re: Issues in wider geographic participation)
John C Klensin wrote: > Similarly, various applications folks within the IETF have > pointed out repeatedly that any approach that assigns multiple > addresses, associated with different networks and different > policies and properties, either requires the applications to > understand those policies, properties, and associated routing > (and blows up all of the historical application-layer APIs in > the process) or requires request/response negotiation that TCP > doesn't allow for (and blows up most of the historical > application-layer APIs). One of the original promises about That is a very old problem of IPv4, except that DNS takes care of multiple addresses of name servers at IP level and SMTP (and some TELNET implementation, though it is not very useful) supports multiple addresses of mail servers at TCP level. Thus, API of IPv4 must change. > IPv6 was no need for changes to TCP and consequent transparency > to most applications. Ha! There is no need for IPv6 specific changes. Masataka Ohta
Re: Not Listening to the Ops Customer (was Re: Issues in wider geographic participation)
--On Friday, May 31, 2013 17:23 -0700 Randy Bush wrote: > < rant > > > the sad fact is that the ietf culture is often not very good at > listening to the (ops) customer. look at the cf we have made > out of ipv6. the end user, and the op, want the absolute > minimal change and cost, let me get an ipv6 allocation from > the integer rental monopoly, flip a switch or two, and get 96 > more bits no magic. 15 years later, dhcp is still a cf, i > have to run a second server (why the hell does isc not merge > them?), i can not use it for finding my gateway or vrrp exit, > ... at least we got rid of the tla/nla classful insanity. but > u/g? puhleeze. Randy, I suggest that characterizing that set of issues as IETF versus Ops is probably not completely right either. For example, with IPv6, the IETF has proposed multiple transition solutions with no roadmap as to which one to apply under what circumstances and growing evidence that some of those solutions are unworkable in practice and others are incompatible with what are claimed to be fundamental and important features of the Internet. It doesn't take a skilled operations person to understand that is a problem; someone with a pointy head and barely enough clue to figure out what a "bit" is much less how many of them are in various addresses can derive a "don't be the first person on the block" or "don't migrate if you can figure out an alternative" lesson from that. Similarly, various applications folks within the IETF have pointed out repeatedly that any approach that assigns multiple addresses, associated with different networks and different policies and properties, either requires the applications to understand those policies, properties, and associated routing (and blows up all of the historical application-layer APIs in the process) or requires request/response negotiation that TCP doesn't allow for (and blows up most of the historical application-layer APIs). One of the original promises about IPv6 was no need for changes to TCP and consequent transparency to most applications. Ha! I have never been convinced that "longer addresses and nothing else" was the only viable solution for IPng, but I don't think it requires an advanced degree in economics to understand that, if the incentives to do something don't exceed the costs and risks of doing it, one shouldn't expect a lot of rational folks to charge off and do it. A complex system with high deployment costs and risks and a dubious set of advantages is not a story that is going to sell itself. And, again, it doesn't require a sophisticated operator to figure that out. None of this takes away from your rant (or Warren's). But I suggest that, on several of the dimensions you identify, the operators are not being singled out for abusive treatment because we don't listen to each other or elementary decision-making or economic realities either... at least where broad issues, rather than fine-tuning of a spec are concerned. john
Re: [IETF] Not Listening to the Ops Customer (was Re: Issues in wider geographic participation)
Warren Kumari wrote: Unfortunately the was a bad case of creeping featuritis and we got: A new, and unfortunately very complex way of resolving L2 addresses. You may use ARP (and DHCP) with IPv6. Extension headers that make it so you cannot actually forward > packets in modern hardware > ( http://tools.ietf.org/html/draft-wkumari-long-headers-00) True. SLAAC, which then required privacy addressing and then fun that > that entails / the DHCP debacle. The problem of SLAAC is that it is stateful in fully distributed manner. That is all the nodes have their own states on address assignment Most operators address ptp Ethernet links with a /30 or /31 in V4. Took a long time to get this in V6 (RFC 6164 - "Using 127-Bit IPv6 Prefixes on Inter-Router Link") and it is still controversial. We ended up in a space where perceived elegance and shiny > features overshadowed what folk actually wanted > -- 96 more bits, no magic. Maybe. But the folk actually needed 8 (or 16 at most) more bits. >> 15 years later, >> dhcp is still a cf, i have to run a second server (why the hell does >> isc not merge them?), i can not use it for finding my gateway or vrrp >> exit, ... at least we got rid of the tla/nla classful insanity. but >> u/g? puhleeze. > > Yup TLA/NLA is a good thing, *IF* multiple addresses of a node and automatic renumbering including routers and DNS were properly supported. It is not very difficult to have done so. Masataka Ohta
Re: [IETF] Re: Issues in wider geographic participation
On May 31, 2013, at 3:56 PM, Randy Bush wrote: >> Yup. And some operators have decided that the IETF document >> development and consensus-forming process is sufficiently annoying >> that they are standing up their own forum for Best Common Practice >> docs: >> http://www.ipbcop.org/ -- "Documented best practices for Engineers by >> Engineers" >> Some more info: >> http://www.internetsociety.org/deploy360/wp-content/uploads/2012/09/Hughes-BCOP.pdf > > actually, that is not operators acting for operators at all. Yup, Randy is 100% correct, this was started, and has gotten much thrust, from non-ops / policy folk. But, the fact that it has gotten some traction / the comments that one hears from ops folk re: how hard it would be to do this in the IETF context is (IMO) telling. > it is yet > another non-ops group trying to colonize ops. documentd best practices > for engineers by policy folk. mission creep on their part, imiho. it > would be amusing if they did not already have a mission that is critical > for all of us. > >> There are BCOPs groups forming / within RIPE, NANOG, etc. > > ripe has published ops practice and even protocol docs for a many years. > as one example, route flap damping came from the ripe doc series. > nanog > may get serious, time will tell. > >> Out of interest, who all from here will be attending NANOG? > > i will be. and saw you at ripe. will you be in lusaka in a week? Unfortunately not -- I had some conflict thing... > >> One (IMO) good idea that was mentioned recently (sorry, I cannot >> remember by whom, may have been Jim Martin) was for someone from the >> IETF to present a short summary of interesting work at NOG meetings. > > this has been done many times. imiho, it has not stirred up much useful > interaction unless the ietfer says something really st00pid. Yes, I may be tilting at windmills, but I think that, if it were done right (short summaries, just enough to pique interest, and then "These are the bits we'd like feedback on, and here is how you can provide it (without joining yet another navel-having mailing list)" it could be really useful. But, doing it right would be the key... > then it > gets amusing. Yes. Maybe it should be designed to present the contentious bits? W > > randy > -- Militant Agnostic -- I don't know and you don't either...
Re: [IETF] Not Listening to the Ops Customer (was Re: Issues in wider geographic participation)
On May 31, 2013, at 8:23 PM, Randy Bush wrote:
> < rant >
>
> the sad fact is that the ietf culture is often not very good at
> listening to the (ops) customer. look at the cf we have made out of
> ipv6. the end user, and the op, want the absolute minimal change and
> cost, let me get an ipv6 allocation from the integer rental monopoly,
> flip a switch or two, and get 96 more bits no magic.
Unfortunatly
Yup, the "issue" with v4 was simply a lack of addresses -- more address bits
was what ops wanted, this probably needed a new protocol number, but that's
about all.
Unfortunately the was a bad case of creeping featuritis and we got:
A new, and unfortunately very complex way of resolving L2 addresses.
Magic IPSec, which then went away again.
Extension headers that make it so you cannot actually forward packets in modern
hardware ( http://tools.ietf.org/html/draft-wkumari-long-headers-00)
SLAAC, which then required privacy addressing and then fun that that entails /
the DHCP debacle.
RA instead of VRRP
Countless transition strategies.
The list goes on and on, but gets depressing really fast.
Operators learnt a number of lessons (the hard way) while operating IPv4
networks that reoccured in new ways in IPv6.
For example, operators learnt that having a large subnet behind a router makes
the router fall over (doing all the ARP processing) during an IP scan. This is
almost identical to the issue described in RFC 6583 ("Operational Neighbor
Discovery Problems")
Operators learnt (a long time back) that allowing source-routing is a really
bad idea, and so a: devices disable it by default and / or b: the standard
templates all have "no ip source-route" (or equivalent). This is almost
identical to the Routing Header issues in V6 (see RFC 5095 - "Deprecation of
Type 0 Routing Headers in IPv6" )
Most operators address ptp Ethernet links with a /30 or /31 in V4. Took a long
time to get this in V6 (RFC 6164 - "Using 127-Bit IPv6 Prefixes on Inter-Router
Link") and it is still controversial.
We ended up in a space where perceived elegance and shiny features overshadowed
what folk actually wanted -- 96 more bits, no magic.
> 15 years later,
> dhcp is still a cf, i have to run a second server (why the hell does
> isc not merge them?), i can not use it for finding my gateway or vrrp
> exit, ... at least we got rid of the tla/nla classful insanity. but
> u/g? puhleeze.
Yup
>
> at ripe/dublin, olaf gave a really nice but somewhat glib talk about
> technology adoption, using dnssec and ipv6 as the positive examples.
Yes, this was a great talk -- I think that it was somewhat glib for the
audience, but having a longer, more in depth version of it at an IETF would
(IMO) be valuable. I think that Olaf has a few versions of that talk…. For folk
who'd like to see the RIPE version - https://ripe66.ripe.net/archives/video/7/
- Innovation at the Waist
> as
> some curmudgeonly schmuck pointed out at the mic, dnssec is forward
> compatible and there are no alternatives, so it is being adopted despite
> its complexity and warts. ipv6 is not forward compatible, we put
> unnecessary obstacles in the deployment path, and there are
> alternatives. d o o m.
>
> if we had wanted ipng deployed, we would have done everything we could
> to make it simple and easy for net-ops and end users to turn it on.
> instead, we made it complex and hard and then blame everyone else for
> not instantly adopting it en masse.
> the ietf did not listen to or
> consider the customer. this is fatal. and the arrogance is taking what
> is left of the e2e internet down the drain with it.
>
+1.
w
> randy
>
--
Don't be impressed with unintelligible stuff said condescendingly.
-- Radia Perlman.
Re: Not Listening to the Ops Customer (was Re: Issues in wider geographic participation)
amen! :) On 31May2013Friday, at 17:23, Randy Bush wrote: > < rant > > > the sad fact is that the ietf culture is often not very good at > listening to the (ops) customer. look at the cf we have made out of > ipv6. the end user, and the op, want the absolute minimal change and > cost, let me get an ipv6 allocation from the integer rental monopoly, > flip a switch or two, and get 96 more bits no magic. 15 years later, > dhcp is still a cf, i have to run a second server (why the hell does > isc not merge them?), i can not use it for finding my gateway or vrrp > exit, ... at least we got rid of the tla/nla classful insanity. but > u/g? puhleeze. > > at ripe/dublin, olaf gave a really nice but somewhat glib talk about > technology adoption, using dnssec and ipv6 as the positive examples. as > some curmudgeonly schmuck pointed out at the mic, dnssec is forward > compatible and there are no alternatives, so it is being adopted despite > its complexity and warts. ipv6 is not forward compatible, we put > unnecessary obstacles in the deployment path, and there are > alternatives. d o o m. > > if we had wanted ipng deployed, we would have done everything we could > to make it simple and easy for net-ops and end users to turn it on. > instead, we made it complex and hard and then blame everyone else for > not instantly adopting it en masse. the ietf did not listen to or > consider the customer. this is fatal. and the arrogance is taking what > is left of the e2e internet down the drain with it. > > randy
Not Listening to the Ops Customer (was Re: Issues in wider geographic participation)
< rant > the sad fact is that the ietf culture is often not very good at listening to the (ops) customer. look at the cf we have made out of ipv6. the end user, and the op, want the absolute minimal change and cost, let me get an ipv6 allocation from the integer rental monopoly, flip a switch or two, and get 96 more bits no magic. 15 years later, dhcp is still a cf, i have to run a second server (why the hell does isc not merge them?), i can not use it for finding my gateway or vrrp exit, ... at least we got rid of the tla/nla classful insanity. but u/g? puhleeze. at ripe/dublin, olaf gave a really nice but somewhat glib talk about technology adoption, using dnssec and ipv6 as the positive examples. as some curmudgeonly schmuck pointed out at the mic, dnssec is forward compatible and there are no alternatives, so it is being adopted despite its complexity and warts. ipv6 is not forward compatible, we put unnecessary obstacles in the deployment path, and there are alternatives. d o o m. if we had wanted ipng deployed, we would have done everything we could to make it simple and easy for net-ops and end users to turn it on. instead, we made it complex and hard and then blame everyone else for not instantly adopting it en masse. the ietf did not listen to or consider the customer. this is fatal. and the arrogance is taking what is left of the e2e internet down the drain with it. randy
RE: [IETF] Re: Issues in wider geographic participation
(I think what Warren, Randy, and others have to say is more relevant to most of this than my opinion - unless you count a handful of end networks with VPN connections among a subset of them, I haven't had either ops responsibility or even direct or indirect management responsibility for those who do for a very long time. I haven't been to a NOG meeting for even longer. And I have absolutely no delusion that I'm current. So the following comments are observations about general principles only.) --On Friday, May 31, 2013 02:19 +0100 Adrian Farrel wrote: > Hi, > > This thread is helpful to me. >... >> ultimately call the IETF's legitimacy and long-term future >> into question. As you suggest, we may have good vendor >> participation but the operators are ultimately the folks who >> pay the vendor's bills. > > I agree so far. > > But who pays the operators' bills, and do we need to encourage > participation at that level as well? The customers of the ISPs. The technical sophistication of those folks and their (non-ISP, non-operator) support structure differs hugely, but most of them neither speak network nor have any desire to learn. That is not necessarily bad. Let me suggest an analogy. The electrical distribution industry has its own standards and standards development processes. In most countries, those standards body attract engineers and designers, but very few of the actual operators who run the power plants and worry about the mains. You presumably pay utility bills (directly or indirectly) and thereby support the whole process. But your ability or mine to plug something into a mains socket and take advantage of the stuff that comes out does not, in general, qualify us to participate in the process of defining transmission standards. And that standards body should probably not lose much sleep over the fact that we aren't showing up. Indeed, if we did show up, we would probably be out of place, wouldn't speak the technical language, and might not understand the culture. At least in my case, if I made a suggestion, it would probably be stupid enough that people would either feel that my presence was wasting their time or would feel obligated to try to explain basic principles to me in the interest of outreach (or both). There are certainly engineers with protocol design background who have ended up with operations responsibilities and acquired a good deal of additional perspective as a result. Several of them have made significant contributions to the IETF and, at least IMO, that dual perspective has helped. But I'm pretty sure that the majority of ops people don't have that background. For those who don't, who needs to know that the equipment and configurations they use will work but who may not have strong preferences about the details of how, and, when things don't work, are a lot more likely to blame vendors (or other ISPs) than us, maybe "how do we get more of them to come to the IETF and participate in the ways that those of us on this list participate" is just not the right question. best, john
Re: [IETF] Re: Issues in wider geographic participation
> Yup. And some operators have decided that the IETF document > development and consensus-forming process is sufficiently annoying > that they are standing up their own forum for Best Common Practice > docs: > http://www.ipbcop.org/ -- "Documented best practices for Engineers by > Engineers" > Some more info: > http://www.internetsociety.org/deploy360/wp-content/uploads/2012/09/Hughes-BCOP.pdf actually, that is not operators acting for operators at all. it is yet another non-ops group trying to colonize ops. documentd best practices for engineers by policy folk. mission creep on their part, imiho. it would be amusing if they did not already have a mission that is critical for all of us. > There are BCOPs groups forming / within RIPE, NANOG, etc. ripe has published ops practice and even protocol docs for a many years. as one example, route flap damping came from the ripe doc series. nanog may get serious, time will tell. > Out of interest, who all from here will be attending NANOG? i will be. and saw you at ripe. will you be in lusaka in a week? > One (IMO) good idea that was mentioned recently (sorry, I cannot > remember by whom, may have been Jim Martin) was for someone from the > IETF to present a short summary of interesting work at NOG meetings. this has been done many times. imiho, it has not stirred up much useful interaction unless the ietfer says something really st00pid. then it gets amusing. randy
Re: [IETF] Re: Issues in wider geographic participation
On May 30, 2013, at 8:37 PM, John C Klensin wrote: > > > --On Thursday, May 30, 2013 15:31 -0400 Warren Kumari > wrote: > >> The below is not a direct response to John, it is more my >> general views on IETF interaction with operators. >> >> So, I've been a long time participant in some NOG's and still >> (perhaps incorrectly) view myself as an operator. I've spent >> significant time thinking about / discussing the issue of >> insufficient operator involvement in the IETF, trying to >> understand some of the causes. I've tried to summarize some of >> the operators' views below, and also some thoughts on how we >> might be able to work better / get more operator input. >> >> I think that at the root of much of the problem is cultural >> differences -- if we want more operator involvement / feedback >> there needs to be some attention paid (by both the operators >> and the IETF folk) to understanding these differences, and >> taking care to respect / accommodate the other side's culture. >> ... > > Warren, > > I think these notes are very helpful, at least insofar as I have > enough knowledge to evaluate. Some of your comments, > including... > >> This is somewhat of a vicious cycle -- operators participate >> less, and so the IETF understands less about how their >> networks run. This leads to solutions that don't understand >> the real world, and so operators lose faith/interest in IETF, >> and participate even less. > > ultimately call the IETF's legitimacy and long-term future into > question. As you suggest, we may have good vendor participation > but the operators are ultimately the folks who pay the vendor's > bills. > >> ... > > As I told someone in another thread, I threw the NOG idea out as > an example without thinking through all of the possible > dynamics. It may be a terrible idea... or even a good idea that > won't work usefully. > > Part of that discussion included an observation that is probably > a corollary to one of yours. Many operators, either > individually or in groups, don't perceive that they have much > incentive to review IETF documents, much less get dragged into > the document development and consensus-forming process. Yup. And some operators have decided that the IETF document development and consensus-forming process is sufficiently annoying that they are standing up their own forum for Best Common Practice docs: http://www.ipbcop.org/ -- "Documented best practices for Engineers by Engineers" Some more info: http://www.internetsociety.org/deploy360/wp-content/uploads/2012/09/Hughes-BCOP.pdf There are BCOPs groups forming / within RIPE, NANOG, etc. This is still early days, but there have been discussions on how these should actually be published, etc. Various ideas have been floated, including bringing them to the IETF once baked, but the IETF stamp, a separate rfc-editor stream, simply publishing them under their own banner, etc. There is a NANOG meeting in New Orleans next week, where more discussions about this will be happening. If I make it to the session I'll try provide some feedback… Out of interest, who all from here will be attending NANOG? Who all attended RIPE in Dublin a few weeks ago? One (IMO) good idea that was mentioned recently (sorry, I cannot remember by whom, may have been Jim Martin) was for someone from the IETF to present a short summary of interesting work at NOG meetings. Someone "from the IETF" could collect short summaries from various WG's and present them at the various NOGs -- these should (IMO) be teaser style summaries, with the most interesting / dynamic bits highlighted. Ideally each WGs would provide a short, concise summary, and then the WG chairs (and folk who wear the smily faced dots on badges) could be designated as contact points, to help take input from operators, provide more detail, info on how you join the WG and participate, etc.. W > Certainly, we are unlikely to get very many people who are not > active IETF participants to do work for the good of the IETF. >> From that perspective, the very best incentive for reviewing a > document pre-standardization is the perceived risk that it will > make one's life worse if it goes through without input from your > perspective. If we throw documents over the wall without clear > motivation as to why people on the other side of the wall should > care,... well, that is as much a setup for failure as the model > in some other Internet bodies of soliciting input and then not > paying any attention to it. (In the latter case, there may be > organizational advantages to being able to say "we received NN > comments", but that does not apply to the IETF.) > > More generally, and borrowing (but altered somewhat) from > another thread: The real point I'm trying to make is that, if > our goal is really to do outreach to other communities to get > better input or reviews with broader perspective, then we better > start thinking more creative
Re: Issues in wider geographic participation
--On Friday, May 31, 2013 12:36 +0200 Fernando Gont wrote: >> if the vendor presence is limited to marketing, sales, and >> perhaps implementation, then, if that is a problem, it is one >> that doesn't lie easily within IETF scope... and probably >> shouldn't. > > Do open source developers count? -- With Android and the like, > they end up producing more deployed implementations than > anyone else. Sure they count. What they often don't do is have the support to attend expensive f2f IETF meetings in far-away places. Holding meetings closer to them might well make everyone feel warm and fuzzy, and that might justify such meeting locations (as I have said more generally all along). But, if we want increased participation from that community, we need to address participation issues and the economics of the way we do business and not think that locating a meeting or two close to people or organizations who don't already participate will make a huge difference. john
Re: [IETF] Re: Issues in wider geographic participation
melinda, i assure you that operations being 'owned' by vendors is not restricted to the geographically isolated. one small example. i was asked to consult on a global deployment by a global fortune whatever company whose name you would all recognize. there was no real management, and the decisions were all done by a mid-level IT tech who was 'owned' by a vendor. when it was clear to me that i was there just to rubber-stamp an ill-considered and ridiculously over-built solution, i walked. otoh, i have worked in some pretty darned isolated environments where the engineers worked very hard to get clue, participated in operator fora, ... come to the afnog workshops in two weeks. > Perhaps we should be thinking about some alternative to engaging > operators by trying to get them to schlep to meetings. Something > along the lines of a liaison process or creating a pipeline between us > and NOGs. actually this has become a popular sport in some segments of the ietf community. a bunch of ietfers come to nog meetings and participate on nog lists. after they got whacked for talking down to operators (the two classics i loved were multiple cases of explainng what the ietf was, and then one arrogant ipv6 ivory tower bigot "the HD ration is a hard problem because operators do not know what a logarithm is"), the interaction has been very useful. i know a highly reputed security researcher who took a year sabbatical and actually worked in ops. some iesg members have been very persistent about gaining ops clue. all in all, there is much more transfer across the membrane in both directions than there was 15 years ago. of course, as most things in life, we could do better. randy
Re: Issues in wider geographic participation
John, On 05/30/2013 08:04 AM, John C Klensin wrote: > irrelevant. If there is a major vendor design presence in a > region, then we should be very concerned if we don't have > significant presence from that region in the IETF as well. But, > if the vendor presence is limited to marketing, sales, and > perhaps implementation, then, if that is a problem, it is one > that doesn't lie easily within IETF scope... and probably > shouldn't. Do open source developers count? -- With Android and the like, they end up producing more deployed implementations than anyone else. And they generally also keep the spirit of "open" more than anyone else. Thanks, -- Fernando Gont SI6 Networks e-mail: fg...@si6networks.com PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
Re: Issues in wider geographic participation
Hi John,
Thanks for your comments/proposals, I always know that your
discussions are important for my progress in IETF. I reply some
comments as below,
On 5/30/13, John C Klensin wrote:
> Jari,
>
> Inspired by two of your recent notes and Dave Crocker's long
> one last weekend (with which I almost completely agree should
> that be notable), let me make a few observations:
>
> (1) To the extent to which the IETF's focus is on protocols that
> we hope vendors and others ("producers" in the vocabulary of
> some other SDOs) will implement and try to get deployed, lines
> of argument that start with "they use the Internet there,
> therefore they should be participating in the IETF" may just be
> irrelevant. If there is a major vendor design presence in a
> region, then we should be very concerned if we don't have
> significant presence from that region in the IETF as well. But,
> if the vendor presence is limited to marketing, sales, and
> perhaps implementation, then, if that is a problem, it is one
> that doesn't lie easily within IETF scope... and probably
> shouldn't.
Yes, let's be explicit, we need to discuss the IETF meeting not
discuss the IETF business, IMHO, meetings are for establishing better
connection between the IETF and the Internet-Community. Does the IETF
have a buildings or locations it is reside in? I see no location,
because it is for the world to participate business remotely.
IMHO, IETF is not just a standards-setting body, please read what it
says about itself:
I disagree, the IETF is not only for protocol-standards, IMHO, it is
for the Internet and its community, please read;
IETF> The mission of the IETF is to make the Internet work better by
producing high quality, relevant technical documents that influence
the way people design, use, and manage the Internet.
IETF> The IETF is a Large open international community of network
designers, operators, vendors, and researchers concerned with the
evolution of the Internet architecture and the and the smooth
operation of the Internet. It is open to any interested individual.
>
> (2) As far as I can tell, the operators in most regions are
> generally well represented in, and collaborate using, the
> various *NOGs. If those groups aren't serving their needs, it
> is probably not a problem for the IETF. If they are, then the
> IETF should no more be trying to invade that turf than a certain
> Geneva-based organization should be invading ours. We are not a
> user group either. To the extent to which there is a need for
> more user groups or more effective ones, I hope that the ISOC
> Chapter structure is at least making useful contributions in the
> area.
I don't know why you exclude users, and separate their participation
to Chapters. The problem of IETF is to give opportunity to regions to
use IETF.
>
> (3) Our Operations and Management Area is mostly about protocols
> and tools (just as the Applications area really isn't about
> applications as user/purchasers normally understand that term)
> and therefore those with the most skin in the game are, again,
> producers, vendors, and designers, not users or even operators.
> The latter are important for figuring out whether a particular
> facility will meet identified needs, but that is typically more
> of a review function than a design one.
The user and operator are mentioned to be part in IETF, please read again;
IETF> The mission of the IETF is to make the Internet work better by
producing high quality, relevant technical documents that influence
the way people design, use, and manage the Internet.
IETF> The IETF is a Large open international community of network
designers, operators, vendors, and researchers concerned with the
evolution of the Internet architecture and the and the smooth
operation of the Internet. It is open to any interested individual.
> If we need more input
> about such specs, we might ask the various *NOGs or similar
> groups to formally review proposed specifications rather than
> depending on people to come to f2f IETF meetings or even to
> follow our mailing lists. So, while closer contact with
> operator communities is always good (and not just for that
> Area), we may need to adjust our expectations to the reality of
> what we can do effectively, rather than forcing on broadening
> participation for its own sake.
Let's make IETF give opportunity to all parts (mentioned in its
mission statement) to participate,
>
> (4) There are some areas of work in the IETF in which very broad
> geographic input --more accurately, broad cultural and
> linguistic input-- are absolutely essential. For example, the
> more we move into internationalization or make decisions that
> dictate or constrain user interfaces, the more danger we get
> into of making really stupid decisions if we don't have broad
> and diverse participation and input. To a degree, the same
> issue shows up in lower layers of the stack. For example, the
> vast majority of us spend our tim
Re: [IETF] Issues in wider geographic participation
On May 30, 2013, at 7:08 PM, Melinda Shore wrote: > On 5/30/13 4:37 PM, John C Klensin wrote: >> ultimately call the IETF's legitimacy and long-term future into >> question. As you suggest, we may have good vendor participation >> but the operators are ultimately the folks who pay the vendor's >> bills. > > Here in Alaska was the first time I'd worked in an environment > that had technologists at a considerably less than elite skill > level, and I'd previously had no idea the extent to which > average operators/data centers rely on vendors (worse: VARs > and consultants) to solve their technical problems. The only > time I'd seen someone from an Alaskan operator participate in > anything to do with the IETF was when one person "voted" on > the transitional address space allocation. I think Warren is > correct to identify this as an issue with operator participation. > > Perhaps we should be thinking about some alternative to > engaging operators by trying to get them to schlep to meetings. > Something along the lines of a liaison process or creating > a pipeline between us and NOGs. Dear Melinda, Perhaps something to also consider is that many installations operate at minimal compliance levels even within advanced regions. The IETF is blessed with many very smart people (at least from my perspective) who also seem overly optimistic of the impact of non-normative language on outcome. Specifications provide better outcomes when function is ensured at minimal levels. In other words, it is better not to make assumptions. Regards, Douglas Otis
Re: [IETF] Re: Issues in wider geographic participation
On 5/30/13 6:21 PM, l.w...@surrey.ac.uk wrote: > You'd love the Pacific. > Few IETFers get exposed to these kinds of environments. I'd had no idea. The point here isn't to derogate techies working in this kind of environment, but that because the sorts of informal technology and skills transfer mechanisms that exist in tech centers don't exist here (people stay in jobs forever, not many new people come in, there's no elite university), there's heavy reliance among operators and enterprise data centers on the people who sell them stuff. I think that this is probably more common than we realize, and might go towards answering questions about where the operators are. Melinda
RE: [IETF] Re: Issues in wider geographic participation
Melinda Shore, all at sea: > Here in Alaska was the first time I'd worked in an environment > that had technologists at a considerably less than elite skill > level, and I'd previously had no idea the extent to which > average operators/data centers rely on vendors (worse: VARs > and consultants) to solve their technical problems. You'd love the Pacific. Few IETFers get exposed to these kinds of environments. Lloyd Wood http://sat-net.com/L.Wood/
Re: [IETF] Re: Issues in wider geographic participation
Hi - > From: "Adrian Farrel" ... > But who pays the operators' bills, and do we need to encourage participation > at > that level as well? Participation as: RFC uptake: - using something based on an RFC? - deploying something based on an RFC? - implementing something based on an RFC? - providing useful feedback based on usage/deployment/implementation experience? I-D uptake: - providing I-D reviews? - implementation of something based on an I-D? - providing useful feedback based on usage/deployment/implementation experience? WG participation: - lurking on mailing list(s)? - useful contribution to email conversation? - participation in meetings? - volunteering as scribe? - volunteer as editor? - design team work? - mentoring newcomers? ... For each of the possible target populations, what would be the realistic motivations to do one or more of these? I think factors to consider would include: - tradeoff between time investment required and hoped-for outcome - perceived likelihood that one's participation would make a difference - perceived extent to which this time investment or contribution (not the same thing!) would be favorably recognized by: + one's peers + one's employer + potential future employers + one's customers / clients - whether there would be any personal satisfaction derived from participation - others? Thinking about the cross-product of these lists and the target populations that have been mentioned, it seems a minor miracle that the IETF has had been able to get as much participation and diversity as it has. Particularly when we get to the "user" level, the time investment / payoff ratio seems all wrong unless that user is highly altruistic or has a generous sponsor with "big picture" motivations. It also seems that for specific target populations, it might be useful to identify (1) the specific ways in which that population might have the most positive impact on the IETF and more importantly (2) identify the ways in which IETF participation might have the biggest positive impact on those types participants, their employers, or other constituencies with whom they identify. Not quite a marketing strategy, but until this conversation is centered around learning the needs, gifts, and motivations of these "other" people, it's not going to accomplish much to increase participation. Randy
Re: [IETF] Re: Issues in wider geographic participation
On 5/30/13 4:37 PM, John C Klensin wrote: > ultimately call the IETF's legitimacy and long-term future into > question. As you suggest, we may have good vendor participation > but the operators are ultimately the folks who pay the vendor's > bills. Here in Alaska was the first time I'd worked in an environment that had technologists at a considerably less than elite skill level, and I'd previously had no idea the extent to which average operators/data centers rely on vendors (worse: VARs and consultants) to solve their technical problems. The only time I'd seen someone from an Alaskan operator participate in anything to do with the IETF was when one person "voted" on the transitional address space allocation. I think Warren is correct to identify this as an issue with operator participation. Perhaps we should be thinking about some alternative to engaging operators by trying to get them to schlep to meetings. Something along the lines of a liaison process or creating a pipeline between us and NOGs. Melinda
RE: [IETF] Re: Issues in wider geographic participation
Hi, This thread is helpful to me. > > This is somewhat of a vicious cycle -- operators participate > > less, and so the IETF understands less about how their > > networks run. This leads to solutions that don't understand > > the real world, and so operators lose faith/interest in IETF, > > and participate even less. > > ultimately call the IETF's legitimacy and long-term future into > question. As you suggest, we may have good vendor participation > but the operators are ultimately the folks who pay the vendor's > bills. I agree so far. But who pays the operators' bills, and do we need to encourage participation at that level as well? Adrian
Re: [IETF] Re: Issues in wider geographic participation
--On Thursday, May 30, 2013 15:31 -0400 Warren Kumari wrote: > The below is not a direct response to John, it is more my > general views on IETF interaction with operators. > > So, I've been a long time participant in some NOG's and still > (perhaps incorrectly) view myself as an operator. I've spent > significant time thinking about / discussing the issue of > insufficient operator involvement in the IETF, trying to > understand some of the causes. I've tried to summarize some of > the operators' views below, and also some thoughts on how we > might be able to work better / get more operator input. > > I think that at the root of much of the problem is cultural > differences -- if we want more operator involvement / feedback > there needs to be some attention paid (by both the operators > and the IETF folk) to understanding these differences, and > taking care to respect / accommodate the other side's culture. >... Warren, I think these notes are very helpful, at least insofar as I have enough knowledge to evaluate. Some of your comments, including... > This is somewhat of a vicious cycle -- operators participate > less, and so the IETF understands less about how their > networks run. This leads to solutions that don't understand > the real world, and so operators lose faith/interest in IETF, > and participate even less. ultimately call the IETF's legitimacy and long-term future into question. As you suggest, we may have good vendor participation but the operators are ultimately the folks who pay the vendor's bills. >... As I told someone in another thread, I threw the NOG idea out as an example without thinking through all of the possible dynamics. It may be a terrible idea... or even a good idea that won't work usefully. Part of that discussion included an observation that is probably a corollary to one of yours. Many operators, either individually or in groups, don't perceive that they have much incentive to review IETF documents, much less get dragged into the document development and consensus-forming process. Certainly, we are unlikely to get very many people who are not active IETF participants to do work for the good of the IETF. >From that perspective, the very best incentive for reviewing a document pre-standardization is the perceived risk that it will make one's life worse if it goes through without input from your perspective. If we throw documents over the wall without clear motivation as to why people on the other side of the wall should care,... well, that is as much a setup for failure as the model in some other Internet bodies of soliciting input and then not paying any attention to it. (In the latter case, there may be organizational advantages to being able to say "we received NN comments", but that does not apply to the IETF.) More generally, and borrowing (but altered somewhat) from another thread: The real point I'm trying to make is that, if our goal is really to do outreach to other communities to get better input or reviews with broader perspective, then we better start thinking more creatively than trying to persuade people (and their organizations and budgets) to sign up for the IETF, three extra week-long meetings a year, reading mailing lists that contain dozens of messages a day on topics that may be of no interest at all, etc. Instead, in your terminology, Warren, we should be looking for ways in which they can do what simultaneously benefits them, us, and the Internet as much as possible within their own cultural framework. At least we need to distinguish between the goals of "better input and review from affected communities" and "increasing IETF active participation". And, coming back to the supposed topic of this thread, dragging circa 1000 people to a place that doesn't have a lot of participation already is unlikely to accomplish either goal. There may be, and probably are, perfectly good reasons why more geographic diversity would be a good idea, but justifying doing so on the basis that it is a good investment in growing long-term active IETF participation just doesn't, IMO, fly. john
Re: [IETF] Re: Issues in wider geographic participation
On May 30, 2013, at 1:24 PM, John C Klensin wrote: > Forwarding a discussion that started offlist for operational > reasons with permission. I've tried to elide some irrelevant > material; I hope that, if Eliot thinks it was relevant after > all, he will add it back in once he gets to an appropriate > machine. > > --On Thursday, May 30, 2013 09:20 -0400 John C Klensin > wrote: > >> --On Thursday, May 30, 2013 08:03 + "Eliot Lear (elear)" >> wrote: >> >>> If we subscribe wholly to this then to borrow from Darth >>> Vader, our failure is complete. As you and I have discussed >>> and debated, our engineering choices make certain assumptions >>> about what problems are high order and which ones we can >>> safely ignore. An example is bandwidth. >> >> Eliot, I think --or at least hope-- that either you have >> misunderstood me or that I have misunderstood your response. >> >> I'm not talking about bandwidth. I'm talking about protocols >> that don't work well under less than optimal circumstances. >> And I'm arguing for awareness and case-by-case understanding of >> tradeoffs, not somehow designing for the bottom. We've seen >> implementations that appear to be in full conformance to IETF >> specifications that simply die with packet timeouts and >> retransmissions. Perhaps that is just failure to document the >> use cases and limitations, perhaps it is failure to describe >> the edge cases and what to do about them. I'm disinclined to >> entirely blame implementers who make a good-faith effort to >> follow IETF specs carefully: if our documents don't permit them >> to get things right, I think at least part of the failure is >> ours for failure to cover those cases in specifications. >> >> We have recognized the issues with some specs and work areas, >> including trying to promote delay-tolerant efforts -- whether >> the environments be Mars or reindeer-based mobile stations in >> areas considerably north of Jari. In others, we have waved >> them off. > > >>> The IETF was formed in part to have rapid impact, and by >>> necessity that required operators and even some users who we >>> later decided to call application developers. >> >> Sure. I'm not suggesting pushing either out. I am suggesting >> that more diversity in those groups would be of benefit. I'm >> also suggesting that, while including people and review >> processes who can speak with good experience from operator >> perspectives would be of huge benefit, that we don't want to >> expand into an operator forum. That means that the operational >> folks we want are operational folks who can also speak usefully >> to protocol issues. As what I think is a corollary, I think >> that beating the bushes in developing countries to try to get >> more operators and end users to attend the IETF as an end in >> itself is not a productive activity from an IETF standpoint. >> And, yes, I think we should be seeking reviewer partnerships >> with the NOGs (and maybe others) for certain classes of >> protocol specifications rather than expecting people who >> frequent those groups to participate actively in the IETF... >> and excluding whatever valuable input they might have if they >> don't. We have tried the latter model and, IMO, failed. The below is not a direct response to John, it is more my general views on IETF interaction with operators. So, I've been a long time participant in some NOG's and still (perhaps incorrectly) view myself as an operator. I've spent significant time thinking about / discussing the issue of insufficient operator involvement in the IETF, trying to understand some of the causes. I've tried to summarize some of the operators' views below, and also some thoughts on how we might be able to work better / get more operator input. I think that at the root of much of the problem is cultural differences -- if we want more operator involvement / feedback there needs to be some attention paid (by both the operators and the IETF folk) to understanding these differences, and taking care to respect / accommodate the other side's culture. Please note: I am discussing the "operator" and "IETF participant" as stereotypes, obviously the reality is much more nuanced than I'm presenting. These stereotypes probably don't include you -- they are simply generalizations to try and present the different sides of the issue. These are some of the concerns I have heard from operators: 1: The work in the IETF simply takes too long. "I actually operate a network, and so I need results *soon*. I really don't want to spend months debating if requiring foo is a 'should' or a 'SHOULD', I just want my feature NOW." "I give $vendor large amounts of money each year -- if I actually want a feature I just wave cash at them / threaten to move to $other_vendor and they'll add it for me." I saw this for myself in DANE. During the time it took us to get chartered, write a use case document, have endless navel-gazing
Re: Issues in wider geographic participation
Forwarding a discussion that started offlist for operational reasons with permission. I've tried to elide some irrelevant material; I hope that, if Eliot thinks it was relevant after all, he will add it back in once he gets to an appropriate machine. --On Thursday, May 30, 2013 09:20 -0400 John C Klensin wrote: > --On Thursday, May 30, 2013 08:03 + "Eliot Lear (elear)" > wrote: > >> If we subscribe wholly to this then to borrow from Darth >> Vader, our failure is complete. As you and I have discussed >> and debated, our engineering choices make certain assumptions >> about what problems are high order and which ones we can >> safely ignore. An example is bandwidth. > > Eliot, I think --or at least hope-- that either you have > misunderstood me or that I have misunderstood your response. > > I'm not talking about bandwidth. I'm talking about protocols > that don't work well under less than optimal circumstances. > And I'm arguing for awareness and case-by-case understanding of > tradeoffs, not somehow designing for the bottom. We've seen > implementations that appear to be in full conformance to IETF > specifications that simply die with packet timeouts and > retransmissions. Perhaps that is just failure to document the > use cases and limitations, perhaps it is failure to describe > the edge cases and what to do about them. I'm disinclined to > entirely blame implementers who make a good-faith effort to > follow IETF specs carefully: if our documents don't permit them > to get things right, I think at least part of the failure is > ours for failure to cover those cases in specifications. > > We have recognized the issues with some specs and work areas, > including trying to promote delay-tolerant efforts -- whether > the environments be Mars or reindeer-based mobile stations in > areas considerably north of Jari. In others, we have waved > them off. >> The IETF was formed in part to have rapid impact, and by >> necessity that required operators and even some users who we >> later decided to call application developers. > > Sure. I'm not suggesting pushing either out. I am suggesting > that more diversity in those groups would be of benefit. I'm > also suggesting that, while including people and review > processes who can speak with good experience from operator > perspectives would be of huge benefit, that we don't want to > expand into an operator forum. That means that the operational > folks we want are operational folks who can also speak usefully > to protocol issues. As what I think is a corollary, I think > that beating the bushes in developing countries to try to get > more operators and end users to attend the IETF as an end in > itself is not a productive activity from an IETF standpoint. > And, yes, I think we should be seeking reviewer partnerships > with the NOGs (and maybe others) for certain classes of > protocol specifications rather than expecting people who > frequent those groups to participate actively in the IETF... > and excluding whatever valuable input they might have if they > don't. We have tried the latter model and, IMO, failed. [...] >> To be sure, the ecosystem is different, and yet we have blind >> spots like spam. Put in the vernacular some of us need to get >> out a bit more. > > As you know, I disagree with you about where the spam-related > blind spots are and what to do about them. But I think that is > a separate issue. We probably agree about getting out more > too. Eliot then responded... --On Thursday, May 30, 2013 15:24 +0200 Eliot Lear wrote: > John, > > On this one point: > > On 5/30/13 3:20 PM, John C Klensin wrote: >> And, yes, I think we should be seeking reviewer partnerships >> with the NOGs (and maybe others) for certain classes of >> protocol specifications rather than expecting people who >> frequent those groups to participate actively in the IETF.. > > Expectations of participation aside, how would you suggest > proceeding wrt NOGs? As you know, I'm opposed to inventing organizational structure unless it is clearly necessary. I would like to ass some IETF-NOG discussions about whether it would be appropriate to announce Last Calls for particularly relevant protocols on their mailing lists and provide a way for relevant operations folks to respond without subjecting themselves to the noise level associated with a subscription to the IETF list. If some NOG wanted to put institutional positions together, I don't think we should object, but I don't think that is either necessary or particularly desirable. If getting good reviews from broader perspectives that way required that we sometimes extend Last Calls to four weeks when RFC 2026 allows two, I think that would be a good tradeoff. I hope we can trust the IESG to make sound decisions about what protocols are particularly relevant and to use feedback from the recipients of those notifications to adjust those decisions if necessary. None of the above
Re: Issues in wider geographic participation
> (2) As far as I can tell, the operators in most regions are > generally well represented in, and collaborate using, the > various *NOGs. the first derivative is generally positive. a lot of fluff, machismo, and posturing, but that seems to come with any endeavor involving us funny monkeys. > We are not a user group either. from the ops' pov, this is not exactly true. it is notable that there are almost no .*vendor user groups (ejk's xr-ug being a rare and useful exception). the ietf is one of the few formal leverage points where we can get change from the vendors. > To the extent to which there is a need for more user groups or more > effective ones, I hope that the ISOC Chapter structure is at least > making useful contributions in the area. the isoc does not attract operators. it is social/political. if we fear the roi to an operator of ietf participation is low, the roi of participation in isoc is vastly lower. but this is not a bug, it's a feature. we do not need more poly/soc folk helping us run our networks. we desperately need them doing the critically needed, and far more difficult, work of providing the socio-political front for the internet. and their talents and achievements in these areas are pretty darned good and getting better every year. randy
Re: Issues in wider geographic participation
Jari,
Inspired by two of your recent notes and Dave Crocker's long
one last weekend (with which I almost completely agree should
that be notable), let me make a few observations:
(1) To the extent to which the IETF's focus is on protocols that
we hope vendors and others ("producers" in the vocabulary of
some other SDOs) will implement and try to get deployed, lines
of argument that start with "they use the Internet there,
therefore they should be participating in the IETF" may just be
irrelevant. If there is a major vendor design presence in a
region, then we should be very concerned if we don't have
significant presence from that region in the IETF as well. But,
if the vendor presence is limited to marketing, sales, and
perhaps implementation, then, if that is a problem, it is one
that doesn't lie easily within IETF scope... and probably
shouldn't.
(2) As far as I can tell, the operators in most regions are
generally well represented in, and collaborate using, the
various *NOGs. If those groups aren't serving their needs, it
is probably not a problem for the IETF. If they are, then the
IETF should no more be trying to invade that turf than a certain
Geneva-based organization should be invading ours. We are not a
user group either. To the extent to which there is a need for
more user groups or more effective ones, I hope that the ISOC
Chapter structure is at least making useful contributions in the
area.
(3) Our Operations and Management Area is mostly about protocols
and tools (just as the Applications area really isn't about
applications as user/purchasers normally understand that term)
and therefore those with the most skin in the game are, again,
producers, vendors, and designers, not users or even operators.
The latter are important for figuring out whether a particular
facility will meet identified needs, but that is typically more
of a review function than a design one. If we need more input
about such specs, we might ask the various *NOGs or similar
groups to formally review proposed specifications rather than
depending on people to come to f2f IETF meetings or even to
follow our mailing lists. So, while closer contact with
operator communities is always good (and not just for that
Area), we may need to adjust our expectations to the reality of
what we can do effectively, rather than forcing on broadening
participation for its own sake.
(4) There are some areas of work in the IETF in which very broad
geographic input --more accurately, broad cultural and
linguistic input-- are absolutely essential. For example, the
more we move into internationalization or make decisions that
dictate or constrain user interfaces, the more danger we get
into of making really stupid decisions if we don't have broad
and diverse participation and input. To a degree, the same
issue shows up in lower layers of the stack. For example, the
vast majority of us spend our time using current-technology
hardware, fast and high-capacity connections to the public
Internet, and even faster LANs. We often subconsciously design
for that sort of environment because we don't encounter the
other kinds on a regular basis. I contend that we have a
relatively poor history of protocol decisions when people are
affected whose day-to-day technology is a decade or two behind
our current experience.
(5) There are a lot of non-vendor participants in the IETF and
even ones whose days as producers of implementations are mostly
over, but it is still a relatively small minority (and, as far
as I can tell, getting smaller). As a member of that group, I
wish it were larger, both for balance and because I think that
we may have an easier time maintaining focus on the overall
well-being of the Internet as a complete system than people
whose focus is getting the next product specified, implemented,
and into the hands of users (or marketing organizations). But,
if we contribute usefully, it is mostly because we bring
considerable experience or perspective of one sort or another to
the table. With rare (and occasionally very important)
exceptions that include people from the research side of the
community, a newly-minted engineer who has no producer
organization affiliation to provide context is unlikely to be
useful to us (and is reasonably likely to have a frustrating
experience no matter what we do about "newcomers" or recruiting).
(6) The IETF is (or has become) primarily an engineering and
protocol design and standardization organization, something that
was recognized over two decades ago when the community kept the
IRTF separate but got rid of all the other non-IETF task forces.
While we could try to "diversify" to include a much broader base
of experience and interests that do not focus directly on our
current range of activities, it is likely that doing so would
increase noise without adding much to the signal.
One thing that all of those observations have in common is that
none of them are likely to be affected by a single
Re: Issues in wider geographic participation
Sorry, I meant LCD. Nthabiseng Pule On 27 May 2013, at 5:48 PM, "John R Levine" wrote: > On Mon, 27 May 2013, Yoav Nir wrote: > >> LCD? > > LDC, Less Developed Country, what used to be called the third world, now that > the second has been bought by the first. > > Regards, > John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY > "I dropped the toothpaste", said Tom, crestfallenly.
Re: Issues in wider geographic participation
Your experience and ideas on how to start-out are useful. On 27 May 2013 16:13, Yoav Nir wrote: > LCD? > > Anyway, What I found most useful when I was starting out 9 years ago, was > to look over the list of areas and working groups ( > http://tools.ietf.org/area/ ) and find out which of them are working on > something that is of interest to me. In my case it was mostly the security > area, and the IPsec working group, since that is what I was working on in > my day job. I subscribed to that list and some others that were also > related to what I was working on (TLS, PKIX). > > So the best thing is to subscribe to the mailing lists, both those that > interest you personally and those that are of interest to your employer (if > there are such groups). > > Step 2 is to lurk for a couple of weeks at least, and just read what > others are posting. If they're talking about a particular draft, it's easy > to find on one of the IETF sites and read it. So you read the drafts, and > read what people are saying about the drafts. This teaches you both about > what the group is working on, and the (for lack of a better term) > "political" part - who are the participants and what are they like. You > might also want to read the Tao document, although different groups have > varying dynamics. > > After a while, you've read the drafts, you've read what some people are > saying, and you may have formed an opinion, either about the draft itself, > or about one of the comments. That's a good time to speak up by sending a > message to the list. Maybe the draft got something wrong. Maybe the comment > is only correct in certain contexts, but doesn't describe some situation > you're familiar with. Maybe in reading the draft you find it hard to figure > out what an implementation should do in a certain case, and you present the > case, and ask that it be clarified. Maybe the proposed protocol would > require clients, servers, or middleboxes to allocate more memory than > implementations that you know can afford. Such comments, and even better, > proposed fixes are how you build a reputation in the IETF for knowing your > stuff. You can also volunteer to review a whole document, or volunteer to > write a missing section. That is how you build a reputation for being > useful. Both are necessary for success in the IETF. > > Step 4 is when you have an idea of your own, or you read someone else's > idea and you want to participate. In that case you either write your own > draft or join someone else in writing one. It's often not enough to just > write it. You also have to get people to read it, post about it to the > correct lists, and in general "sell" it and gather support. It is at about > that time that you start to feel the need to attend meetings, but you can > get some things done even without it. > > Hope this helps > > Yoav > > On May 27, 2013, at 3:33 PM, Nthabiseng Pule > wrote: > > > as, > > > > I am new to the IETF. I would like to contribute any way I can, but the > learning curve seems steep indeed. I am from an LCD country. I have the > necessary resources but I just don't know where to start. > > > > Some guidance would be welcome. I am reading on stuff and hope that one > day I will be able to make some meaningful contribution. > > > > > > Nthabiseng Pule > > > > > > > > On 27 May 2013, at 1:52 PM, Arturo Servin wrote: > > > >> John, > >> > >> Good summary. > >> > >> I would add a "steep learning-curve" to start participating. It takes > time to get conformable in participating in mailing list and reviewing > drafts for I think two reasons. One is to get know how the IETF works, and > another to catch-up in knowing the topic in relation with other WG > participants. > >> > >> About the remote hub I think it would be good to give it a try. > >> > >> Regards, > >> as > >> > >> On 27 May 2013, at 02:52, John Levine wrote: > >> > >>> I think this is a summary of the issues people have mentioned that > >>> discourage participation from LDCs, in rough order of importance. > >>> > >>> * People aren't aware the IETF exists, or what it does, or that it has > >>> an open participation model > >>> > >>> * People don't read and write English well enough to be comfortable > >>> participating > >>> > >>> * People are unaccustomed to and perhaps uncomfortable expressing > >>> overt disagreement > >>> > >>> * People don't think they have anything to contribute to an > organization > >>> that is mostly people from rich countries > >>> > >>> * People don't have adequate Internet access for mail, or to use the > >>> remote participation tools > >>> > >>> I have to say that I don't see one or two meetings in South America > >>> addressing any of these. Given that the incremental cost to the > >>> participants, compared to meeting in North America, would likely be on > >>> the order of a million dollars, it seems to me very likely that there > >>> are better ways to spend the money. > >>> > >>> For example, if language
Re: Issues in wider geographic participation
I would prefer that people come to the IETF because they have a problem and they are looking for ways to solve it ... as opposed to wanting to work with the IETF for some reason and looking for something "the IETF" wants them to work on. The former feels like engineering, the latter like professional standards going. Therefore, if someone says they are looking for a problem to work on, I ask them to bring a problem with them.
Re: Issues in wider geographic participation
On Sun, 26 May 2013, Melinda Shore wrote: > It also seems unlikely to me that that million dollars is otherwise > available. > > I like the idea of setting up a remote participation center (doubly- > so if one or more very experienced IETFers who spoke the local language > could be on-site) but it seems very unlikely to me that, say, a Frobnitz > Networks employee would be able to convinced Frobnitz Networks to send > the $400 saved by not going to Buenos Aires to such an undertaking. Your are likely right, but the discussion hasn't included the negative impression on Frobnitz management re. the added expense. Just because the money can't be 'recovered' for other use, doesn't make it rational to spend it.
Re: Issues in wider geographic participation
The idea that I had for this remote participation hub was to "break the ice". I saw no problem to provide some facilities to newcomers are more comfortable. Perhaps, later that would encourage them to improve their English and participate. But these are just ideas. .as On 5/27/13 1:30 PM, John R Levine wrote: >>> Translation ?? This a very old discussion and moot point, people that >>> have interest to participate in this type of international forums and >>> processes SHOULD learn English. > >> Another barrier. >> >> Anyway we are talking about remote participation only. > > You guys would know better than us gringos, but how likely is it that > having translation available for live sessions would encourage people to > use their limited English to work through drafts and try some e-mail? > > Regards, > John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY > "I dropped the toothpaste", said Tom, crestfallenly.
Re: Issues in wider geographic participation
On 5/27/13 12:41 PM, Jorge Amodio wrote: > > Translation ?? This a very old discussion and moot point, people that have > interest to participate in this type of international forums and processes > SHOULD learn English. > > -Jorge > Another barrier. Anyway we are talking about remote participation only. .as
Re: Issues in wider geographic participation
Translation ?? This a very old discussion and moot point, people that have interest to participate in this type of international forums and processes SHOULD learn English. Another barrier. Anyway we are talking about remote participation only. You guys would know better than us gringos, but how likely is it that having translation available for live sessions would encourage people to use their limited English to work through drafts and try some e-mail? Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly. smime.p7s Description: S/MIME Cryptographic Signature
Re: Issues in wider geographic participation
On 5/27/13 11:15 AM, SM wrote: > > Joel Jaeggli mentioned that a regional NOG is not fertile ground for new > IETF participants. Is LACNOG fertile ground for new IETF participants? I guess so. We have doing some efforts in the past and we are planning to do more. You will see some recurrent participants to both places (ietf and lacnog). > > The "sending email, comments, reviewing draft" is the really difficult > part. My uneducated guess is that it would takes months of work. It's > not as negative as it sounds if you consider that overcoming the barrier > of entry might usually take over a year. It is no negative in deed. It is just plain hard. > > Could you ask the people who attended the talk ( > http://www.youtube.com/watch?v=L_zacX9DcZA ) to provide some feedback > about it to edu-discuss mailing list? Sure, I will do that. Regards, as
Re: Issues in wider geographic participation
Hi Jari, On Mon, May 27, 2013 at 5:15 AM, Jari Arkko wrote: > John, > > > * People aren't aware the IETF exists, or what it does, or that it has > > an open participation model > > > > * People don't read and write English well enough to be comfortable > > participating > > > > * People are unaccustomed to and perhaps uncomfortable expressing > > overt disagreement > > > > * People don't think they have anything to contribute to an organization > > that is mostly people from rich countries > > > > * People don't have adequate Internet access for mail, or to use the > > remote participation tools > > Thanks for sending out a list of potential issues. > > I think there may be one issue missing from the list. At the end of the > day, what tends to drive people actual, concrete benefit to themselves or > their organisations. A drive that is so big that it forces you to cross > language and other barriers and make at least a time investment in > participation. As an example, the number of Chinese participants has > increased rapidly in the IETF. Why? We probably didn't suddenly get much > better at welcoming new people at the IETF, but the new participants felt > that work on the Internet is important to them personally, and their > organisations felt that they need to be part of making Internet standards. > This isn't very surprising, given, for instance, the rise of the Chinese > technology industry to a very visible role in the world. > > So I feel that the issue in many cases is simpler than the ones in the > list: "What's in it for me"? This obviously has to do with the role of > vendors in the IETF and the distribution of tech industry in the world. It > may also have something to do with doing things that are important. I'm > sure we could be working on topics that are even better aligned to what the > world needs… if the people who need them were here to tell us :-) > > This is the most important factor and trumps all other combined. If the standards work is relevant to your business or research then the probability that you will participate in the IETF goes way up. I think many people on this list forget how different doing engineering in the IETF is from engineering for a private enterprise. Tasks that take 1 or 2 months in a private enterprise often take 1 or 2 years (or more!). Competitors working on a standard have a completely different set of incentives than employees working on a product, so agreement on standards is much harder to achieve. Newbies can have a hard time adjusting to these differences. > The IETF can't change the distribution of industries in the world, but we > can, for instance, focus on the vendors that are there or work more on > topics that are interesting for the operational folks. The latter would be > a good idea for the IETF, anyway. > > > For example, if language and net access is a problem, it might be > > interesting to set up a remote participation center in B.A. during one > > of the North American meetings (it's one time zone off from Toronto) > > We've been looking at setting up something like that (not for BA > specifically). > > Jari > > Andy
Re: Issues in wider geographic participation
On Mon, 27 May 2013, Yoav Nir wrote: LCD? LDC, Less Developed Country, what used to be called the third world, now that the second has been bought by the first. Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly. smime.p7s Description: S/MIME Cryptographic Signature
Re: Issues in wider geographic participation
Translation ?? This a very old discussion and moot point, people that have interest to participate in this type of international forums and processes SHOULD learn English. -Jorge On May 27, 2013, at 7:17 AM, Arturo Servin wrote: > >Translation? > >Also, it would be important that the "local" people/helpers could do an > introduction to what it is the ietf, how to send comments in the remote > participation, to the list, what's a WG etc. It may sound a bit bureaucratic, > but if we want to have these remote people to start sending emails, comments, > reviewing draft we need to break the "ice" somehow. It does not have to be > extensive, a short intro could be enough. > >About a serious proposal, are you thinking in an I+D, wg or something > coming from the IESG, IAOC? > > /as > > On 27 May 2013, at 09:07, Dave Crocker wrote: > >> On 5/27/2013 1:52 PM, Arturo Servin wrote: >>>About the remote hub I think it would be good to give it a try. >> >> >> I'm increasingly intrigued by this idea. It could be interesting to try to >> formulate a serious proposal for this, with enough detail to qualify as a >> functional specification. The easy part is specifying audio/video streams >> support. More challenging is to get the personal and personnel support >> figured out. >> >> And should it have some means of assisting discussions outside of the >> bof/wg/plenary sessions? >> >> What else? >> >> d/ >> >> -- >> Dave Crocker >> Brandenburg InternetWorking >> bbiw.net >
Re: Issues in wider geographic participation
On May 27, 2013, at 5:23 PM, Dave Crocker wrote: > On 5/27/2013 4:13 PM, Yoav Nir wrote: >> Anyway, What I found most useful when I was starting out 9 years ago, > > > One might wish for a document that gives such guidance to folk who are new to > the IETF. > > And indeed... > > The Tao of IETF: A Novice's Guide to the Internet Engineering > Task Force > > http://www.ietf.org/tao.html > > If the content needs to be improved, let's do it! Yes, and for extra credit you can read RFC 4144. I find it hard to improve on the Tao, but I think that its target audience are people who are ready to plunge - review documents, attend meetings, write drafts. It took me over a year of mostly lurking and little discussion to get there. Others may be quicker. I've also found that it's hard to make generalizations about working groups and their associated mailing lists. Some are low-traffic, some have 50 messages a day. Some discuss protocols in abstract terms, while others take the "running code" part seriously. Some have dominant chairs that moderate the discussion such that all threads become dialogs with the chairs, while in others the chairs move out of the way to let the discussion flow. Some have dominant experts and everyone waits for their (final?) word on the subject, while at others not only everyone may speak, but almost everyone is listened to. Regardless of what we would like groups to be like, I think it's important - particularly for a newcomer - to lurk for a while and get a "feel" for the working group. Otherwise you get into arguments with the local crank that everyone else knows to ignore (I've done this lots and lots of times). Another think I've learned is that you don't necessarily end up being involved in the things you came into the IETF for. I came to the IETF to follow things that were important to my part of the company: IPsec, TLS, PKIX. I ended up contributing in MSec, and finally chairing the WebSec group, which is really far away from my day job. Interestingly, a lot of the same people show up in different working groups, so it works very well to do work in one group, while still following the groups that you came in for. IOW my ability to follow the groups that are related to my day job is enhanced by being active in other working groups. That was kind of surprising to me at first. So like the Tao says, take the plunge. The more you're involved in something, the more you can do in other things. Much of being effective in the IETF is about knowing people and making yourself useful to them. Yoav
Re: Issues in wider geographic participation
Hi, About the remote hub I think it would be good to give it a try. I'm increasingly intrigued by this idea. It could be interesting to try to formulate a serious proposal for this, with enough detail to qualify as a functional specification. The easy part is specifying audio/video streams support. More challenging is to get the personal and personnel support figured out. I think most of research/university networks are facing same challenge. Remote class setup is exactly what we need (with support of back a/v channel). Not a rocket science, but can be expensive in case of support in number of parallel tracks. There is also a question if IETF wants to cover only room-to-room setup or want to cover room-to-desktop scenario. And should it have some means of assisting discussions outside of the bof/wg/plenary sessions? Having a mechanism for "voting" has also some value. my $0.02 Regards Michal
Re: Issues in wider geographic participation
Hola Arturo, At 05:17 27-05-2013, Arturo Servin wrote: Also, it would be important that the "local" people/helpers could do an introduction to what it is the ietf, how to send comments in the remote participation, to the list, what's a WG etc. It may sound a bit bureaucratic, but if we want to have these remote people to start sending emails, comments, reviewing draft we need to break the "ice" somehow. It does not have to be extensive, a short intro could be enough. I like what you said about breaking the ice. As mentioned above, having local people would help. There is a Newcomers tutorial which explains what is a working group, what is the IETF, etc. Joel Jaeggli mentioned that a regional NOG is not fertile ground for new IETF participants. Is LACNOG fertile ground for new IETF participants? The "sending email, comments, reviewing draft" is the really difficult part. My uneducated guess is that it would takes months of work. It's not as negative as it sounds if you consider that overcoming the barrier of entry might usually take over a year. Could you ask the people who attended the talk ( http://www.youtube.com/watch?v=L_zacX9DcZA ) to provide some feedback about it to edu-discuss mailing list? Regards, -sm
Re: Issues in wider geographic participation
On 5/27/2013 4:13 PM, Yoav Nir wrote: Anyway, What I found most useful when I was starting out 9 years ago, One might wish for a document that gives such guidance to folk who are new to the IETF. And indeed... The Tao of IETF: A Novice's Guide to the Internet Engineering Task Force http://www.ietf.org/tao.html If the content needs to be improved, let's do it! d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: Issues in wider geographic participation
LCD? Anyway, What I found most useful when I was starting out 9 years ago, was to look over the list of areas and working groups ( http://tools.ietf.org/area/ ) and find out which of them are working on something that is of interest to me. In my case it was mostly the security area, and the IPsec working group, since that is what I was working on in my day job. I subscribed to that list and some others that were also related to what I was working on (TLS, PKIX). So the best thing is to subscribe to the mailing lists, both those that interest you personally and those that are of interest to your employer (if there are such groups). Step 2 is to lurk for a couple of weeks at least, and just read what others are posting. If they're talking about a particular draft, it's easy to find on one of the IETF sites and read it. So you read the drafts, and read what people are saying about the drafts. This teaches you both about what the group is working on, and the (for lack of a better term) "political" part - who are the participants and what are they like. You might also want to read the Tao document, although different groups have varying dynamics. After a while, you've read the drafts, you've read what some people are saying, and you may have formed an opinion, either about the draft itself, or about one of the comments. That's a good time to speak up by sending a message to the list. Maybe the draft got something wrong. Maybe the comment is only correct in certain contexts, but doesn't describe some situation you're familiar with. Maybe in reading the draft you find it hard to figure out what an implementation should do in a certain case, and you present the case, and ask that it be clarified. Maybe the proposed protocol would require clients, servers, or middleboxes to allocate more memory than implementations that you know can afford. Such comments, and even better, proposed fixes are how you build a reputation in the IETF for knowing your stuff. You can also volunteer to review a whole document, or volunteer to write a missing section. That is how you build a reputation for being useful. Both are necessary for success in the IETF. Step 4 is when you have an idea of your own, or you read someone else's idea and you want to participate. In that case you either write your own draft or join someone else in writing one. It's often not enough to just write it. You also have to get people to read it, post about it to the correct lists, and in general "sell" it and gather support. It is at about that time that you start to feel the need to attend meetings, but you can get some things done even without it. Hope this helps Yoav On May 27, 2013, at 3:33 PM, Nthabiseng Pule wrote: > as, > > I am new to the IETF. I would like to contribute any way I can, but the > learning curve seems steep indeed. I am from an LCD country. I have the > necessary resources but I just don't know where to start. > > Some guidance would be welcome. I am reading on stuff and hope that one day I > will be able to make some meaningful contribution. > > > Nthabiseng Pule > > > > On 27 May 2013, at 1:52 PM, Arturo Servin wrote: > >> John, >> >> Good summary. >> >> I would add a "steep learning-curve" to start participating. It takes time >> to get conformable in participating in mailing list and reviewing drafts for >> I think two reasons. One is to get know how the IETF works, and another to >> catch-up in knowing the topic in relation with other WG participants. >> >> About the remote hub I think it would be good to give it a try. >> >> Regards, >> as >> >> On 27 May 2013, at 02:52, John Levine wrote: >> >>> I think this is a summary of the issues people have mentioned that >>> discourage participation from LDCs, in rough order of importance. >>> >>> * People aren't aware the IETF exists, or what it does, or that it has >>> an open participation model >>> >>> * People don't read and write English well enough to be comfortable >>> participating >>> >>> * People are unaccustomed to and perhaps uncomfortable expressing >>> overt disagreement >>> >>> * People don't think they have anything to contribute to an organization >>> that is mostly people from rich countries >>> >>> * People don't have adequate Internet access for mail, or to use the >>> remote participation tools >>> >>> I have to say that I don't see one or two meetings in South America >>> addressing any of these. Given that the incremental cost to the >>> participants, compared to meeting in North America, would likely be on >>> the order of a million dollars, it seems to me very likely that there >>> are better ways to spend the money. >>> >>> For example, if language and net access is a problem, it might be >>> interesting to set up a remote participation center in B.A. during one >>> of the North American meetings (it's one time zone off from Toronto) >>> with screens and cameras, paid interpreters,
Re: Issues in wider geographic participation
Ditto. On 27 May 2013 14:33, Nthabiseng Pule wrote: > as, > > I am new to the IETF. I would like to contribute any way I can, but the > learning curve seems steep indeed. I am from an LCD country. I have the > necessary resources but I just don't know where to start. > > Some guidance would be welcome. I am reading on stuff and hope that one > day I will be able to make some meaningful contribution. > > > Nthabiseng Pule > > > > On 27 May 2013, at 1:52 PM, Arturo Servin wrote: > > > John, > > > >Good summary. > > > >I would add a "steep learning-curve" to start participating. It takes > time to get conformable in participating in mailing list and reviewing > drafts for I think two reasons. One is to get know how the IETF works, and > another to catch-up in knowing the topic in relation with other WG > participants. > > > >About the remote hub I think it would be good to give it a try. > > > > Regards, > > as > > > > On 27 May 2013, at 02:52, John Levine wrote: > > > >> I think this is a summary of the issues people have mentioned that > >> discourage participation from LDCs, in rough order of importance. > >> > >> * People aren't aware the IETF exists, or what it does, or that it has > >> an open participation model > >> > >> * People don't read and write English well enough to be comfortable > >> participating > >> > >> * People are unaccustomed to and perhaps uncomfortable expressing > >> overt disagreement > >> > >> * People don't think they have anything to contribute to an organization > >> that is mostly people from rich countries > >> > >> * People don't have adequate Internet access for mail, or to use the > >> remote participation tools > >> > >> I have to say that I don't see one or two meetings in South America > >> addressing any of these. Given that the incremental cost to the > >> participants, compared to meeting in North America, would likely be on > >> the order of a million dollars, it seems to me very likely that there > >> are better ways to spend the money. > >> > >> For example, if language and net access is a problem, it might be > >> interesting to set up a remote participation center in B.A. during one > >> of the North American meetings (it's one time zone off from Toronto) > >> with screens and cameras, paid interpreters, and a few volunteers to > >> help explain what's going on. > >> > >> R's, > >> John > > >
Re: Issues in wider geographic participation
as, I am new to the IETF. I would like to contribute any way I can, but the learning curve seems steep indeed. I am from an LCD country. I have the necessary resources but I just don't know where to start. Some guidance would be welcome. I am reading on stuff and hope that one day I will be able to make some meaningful contribution. Nthabiseng Pule On 27 May 2013, at 1:52 PM, Arturo Servin wrote: > John, > >Good summary. > >I would add a "steep learning-curve" to start participating. It takes time > to get conformable in participating in mailing list and reviewing drafts for > I think two reasons. One is to get know how the IETF works, and another to > catch-up in knowing the topic in relation with other WG participants. > >About the remote hub I think it would be good to give it a try. > > Regards, > as > > On 27 May 2013, at 02:52, John Levine wrote: > >> I think this is a summary of the issues people have mentioned that >> discourage participation from LDCs, in rough order of importance. >> >> * People aren't aware the IETF exists, or what it does, or that it has >> an open participation model >> >> * People don't read and write English well enough to be comfortable >> participating >> >> * People are unaccustomed to and perhaps uncomfortable expressing >> overt disagreement >> >> * People don't think they have anything to contribute to an organization >> that is mostly people from rich countries >> >> * People don't have adequate Internet access for mail, or to use the >> remote participation tools >> >> I have to say that I don't see one or two meetings in South America >> addressing any of these. Given that the incremental cost to the >> participants, compared to meeting in North America, would likely be on >> the order of a million dollars, it seems to me very likely that there >> are better ways to spend the money. >> >> For example, if language and net access is a problem, it might be >> interesting to set up a remote participation center in B.A. during one >> of the North American meetings (it's one time zone off from Toronto) >> with screens and cameras, paid interpreters, and a few volunteers to >> help explain what's going on. >> >> R's, >> John >
Re: Issues in wider geographic participation
John, > * People aren't aware the IETF exists, or what it does, or that it has > an open participation model > > * People don't read and write English well enough to be comfortable > participating > > * People are unaccustomed to and perhaps uncomfortable expressing > overt disagreement > > * People don't think they have anything to contribute to an organization > that is mostly people from rich countries > > * People don't have adequate Internet access for mail, or to use the > remote participation tools Thanks for sending out a list of potential issues. I think there may be one issue missing from the list. At the end of the day, what tends to drive people actual, concrete benefit to themselves or their organisations. A drive that is so big that it forces you to cross language and other barriers and make at least a time investment in participation. As an example, the number of Chinese participants has increased rapidly in the IETF. Why? We probably didn't suddenly get much better at welcoming new people at the IETF, but the new participants felt that work on the Internet is important to them personally, and their organisations felt that they need to be part of making Internet standards. This isn't very surprising, given, for instance, the rise of the Chinese technology industry to a very visible role in the world. So I feel that the issue in many cases is simpler than the ones in the list: "What's in it for me"? This obviously has to do with the role of vendors in the IETF and the distribution of tech industry in the world. It may also have something to do with doing things that are important. I'm sure we could be working on topics that are even better aligned to what the world needs… if the people who need them were here to tell us :-) The IETF can't change the distribution of industries in the world, but we can, for instance, focus on the vendors that are there or work more on topics that are interesting for the operational folks. The latter would be a good idea for the IETF, anyway. > For example, if language and net access is a problem, it might be > interesting to set up a remote participation center in B.A. during one > of the North American meetings (it's one time zone off from Toronto) We've been looking at setting up something like that (not for BA specifically). Jari
Re: Issues in wider geographic participation
Add: like many organizations around the world including the USA, they don't think it's worth the huge effort to develop standards when they can rely on others to do so well enough for their needs.
Re: Issues in wider geographic participation
Translation? Also, it would be important that the "local" people/helpers could do an introduction to what it is the ietf, how to send comments in the remote participation, to the list, what's a WG etc. It may sound a bit bureaucratic, but if we want to have these remote people to start sending emails, comments, reviewing draft we need to break the "ice" somehow. It does not have to be extensive, a short intro could be enough. About a serious proposal, are you thinking in an I+D, wg or something coming from the IESG, IAOC? /as On 27 May 2013, at 09:07, Dave Crocker wrote: > On 5/27/2013 1:52 PM, Arturo Servin wrote: >> About the remote hub I think it would be good to give it a try. > > > I'm increasingly intrigued by this idea. It could be interesting to try to > formulate a serious proposal for this, with enough detail to qualify as a > functional specification. The easy part is specifying audio/video streams > support. More challenging is to get the personal and personnel support > figured out. > > And should it have some means of assisting discussions outside of the > bof/wg/plenary sessions? > > What else? > > d/ > > -- > Dave Crocker > Brandenburg InternetWorking > bbiw.net
Re: Issues in wider geographic participation
On 5/27/2013 1:52 PM, Arturo Servin wrote: About the remote hub I think it would be good to give it a try. I'm increasingly intrigued by this idea. It could be interesting to try to formulate a serious proposal for this, with enough detail to qualify as a functional specification. The easy part is specifying audio/video streams support. More challenging is to get the personal and personnel support figured out. And should it have some means of assisting discussions outside of the bof/wg/plenary sessions? What else? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: Issues in wider geographic participation
John, Good summary. I would add a "steep learning-curve" to start participating. It takes time to get conformable in participating in mailing list and reviewing drafts for I think two reasons. One is to get know how the IETF works, and another to catch-up in knowing the topic in relation with other WG participants. About the remote hub I think it would be good to give it a try. Regards, as On 27 May 2013, at 02:52, John Levine wrote: > I think this is a summary of the issues people have mentioned that > discourage participation from LDCs, in rough order of importance. > > * People aren't aware the IETF exists, or what it does, or that it has > an open participation model > > * People don't read and write English well enough to be comfortable > participating > > * People are unaccustomed to and perhaps uncomfortable expressing > overt disagreement > > * People don't think they have anything to contribute to an organization > that is mostly people from rich countries > > * People don't have adequate Internet access for mail, or to use the > remote participation tools > > I have to say that I don't see one or two meetings in South America > addressing any of these. Given that the incremental cost to the > participants, compared to meeting in North America, would likely be on > the order of a million dollars, it seems to me very likely that there > are better ways to spend the money. > > For example, if language and net access is a problem, it might be > interesting to set up a remote participation center in B.A. during one > of the North American meetings (it's one time zone off from Toronto) > with screens and cameras, paid interpreters, and a few volunteers to > help explain what's going on. > > R's, > John > > >
Re: Issues in wider geographic participation
Hi John, I agree and I will add, that What makes that participant continue to volunteer, or even witness/read the ietf work process? Making someone interested to do something freely is not an easy task. The difficulty is how to make that individual participate with value, he/she may need help to notice that *IETF needs* their regional-participation. Example, I got once a response that IETF or WG chair's jobs are not to educate others, but who said that IETF is better educated or that WG chairs are better educated than others. It always depends on the relativity of education with the region needs, not only eduaction related to the Internet technology. I think we *need* in IETF to gain all best educated people of world-regions into IETF (volunteering), so that we make the Internet better for the WORLD, because technology SHOULD follow the community-regional *needs*. Not that we need to gain best standard/technology experts to make all regions follow the technology-product requirements, because will may never be *used* that way :-) Comments below, AB On 5/27/13, John Levine wrote: > I think this is a summary of the issues people have mentioned that > discourage participation from LDCs, in rough order of importance. > > * People aren't aware the IETF exists, or what it does, or that it has > an open participation model Also IMHO, the IETF is not aware of existance of Internet community-regional *needs* for their better Internet technology future, > > * People don't read and write English well enough to be comfortable > participating That is not an issue, well educated people around the world know english reasonably, but the problem is that many of current IETF participants like to read correct english, hope they change to adapt to the World's English. > > * People are unaccustomed to and perhaps uncomfortable expressing > overt disagreement That is true, but mostly Chairs and editors are responsible to make that continue or stop. > > * People don't think they have anything to contribute to an organization > that is mostly people from rich countries This point is important, please read my addition above. > > * People don't have adequate Internet access for mail, or to use the > remote participation tools Yes that is true, but also we need people like old participants, or 98% of participants to get use to participating remotely at IETF meetings. I don't want to see complains on journey expenses of money but of spending-time is ok :Z > > I have to say that I don't see one or two meetings in South America > addressing any of these. Given that the incremental cost to the > participants, compared to meeting in North America, would likely be on > the order of a million dollars, it seems to me very likely that there > are better ways to spend the money. I don't care how much money spent, we SHOULD focus on how much time gained by IETF and how much volunteer-time spent for IETF. Attendance can spend the same time remotely, the World is well connected now, > > For example, if language and net access is a problem, it might be > interesting to set up a remote participation center in B.A. during one > of the North American meetings (it's one time zone off from Toronto) > with screens and cameras, paid interpreters, and a few volunteers to > help explain what's going on. I think the problem is contribution access to IETF. We need centers to increase access to documents-produced per regions, centers to increase participants per region, centers to increase remote users per regions, etc. > > R's, > John > > > > >
Re: Issues in wider geographic participation
On 5/26/13 9:52 PM, John Levine wrote: > I have to say that I don't see one or two meetings in South America > addressing any of these. I don't, either. However, > Given that the incremental cost to the > participants, compared to meeting in North America, would likely be on > the order of a million dollars, it seems to me very likely that there > are better ways to spend the money. It also seems unlikely to me that that million dollars is otherwise available. I like the idea of setting up a remote participation center (doubly- so if one or more very experienced IETFers who spoke the local language could be on-site) but it seems very unlikely to me that, say, a Frobnitz Networks employee would be able to convinced Frobnitz Networks to send the $400 saved by not going to Buenos Aires to such an undertaking. Melinda
Issues in wider geographic participation
I think this is a summary of the issues people have mentioned that discourage participation from LDCs, in rough order of importance. * People aren't aware the IETF exists, or what it does, or that it has an open participation model * People don't read and write English well enough to be comfortable participating * People are unaccustomed to and perhaps uncomfortable expressing overt disagreement * People don't think they have anything to contribute to an organization that is mostly people from rich countries * People don't have adequate Internet access for mail, or to use the remote participation tools I have to say that I don't see one or two meetings in South America addressing any of these. Given that the incremental cost to the participants, compared to meeting in North America, would likely be on the order of a million dollars, it seems to me very likely that there are better ways to spend the money. For example, if language and net access is a problem, it might be interesting to set up a remote participation center in B.A. during one of the North American meetings (it's one time zone off from Toronto) with screens and cameras, paid interpreters, and a few volunteers to help explain what's going on. R's, John
