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 Meeting in South America
On 5/30/13, George Michaelson wrote: > At risk of alienating my comrades from locations seeking to attract an IETF > for local development/inclusiveness and the like reasons, I think John gets > to the nub of the matter: the wider community cost, borne by all attendees > as a 'silent tax' is really very high, for this outcome. We need to be > explicit this is what we're doing. The ISOC grants are probably a more cost > effective way of boosting participation from outlier economies right now. Yes, let's be explicit, what is the meeting values or goals? Why we are considering cost now when we are looking into the IETF future challenges, or when we are looking into developing IETF activities (i.e. better outcome change) > So lets be explicit. This is a standards-setting body, which is discussing > outreach, inclusiveness, wider participation outcomes, and the cost > consequences on attendance where the core motivation is standards setting. 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. IMHO, IETF is not just a standards-setting body, please read what it says about itself: 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. AB> so interested individuals are welcomed in the IETF meetings and business. > If the core motivations are changing, maybe that drives things in a > different way? > Don't forget that the Internet is changing and that the Internet Community is changing, the IETF SHOULD follow thoes changes :-) AB
Weekly posting summary for ietf@ietf.org
Total of 283 messages in the last 7 days. script run at: Fri May 31 00:53:02 EDT 2013 Messages | Bytes| Who +--++--+ 6.71% | 19 | 6.76% | 149502 | abdussalambar...@gmail.com 5.30% | 15 | 4.74% | 104777 | jul...@braga.eti.br 4.59% | 13 | 4.81% | 106323 | john-i...@jck.com 4.95% | 14 | 4.05% |89568 | melinda.sh...@gmail.com 4.24% | 12 | 4.09% |90539 | s...@resistor.net 3.53% | 10 | 3.01% |66505 | d...@dcrocker.net 3.53% | 10 | 2.90% |64207 | joe...@bogus.com 3.18% |9 | 2.48% |54808 | aser...@lacnic.net 2.83% |8 | 2.49% |54963 | arturo.ser...@gmail.com 1.77% |5 | 3.36% |74410 | r...@ipv.sx 2.47% |7 | 2.53% |56045 | jmamo...@gmail.com 2.47% |7 | 2.32% |51295 | jo...@taugh.com 2.47% |7 | 2.09% |46177 | jari.ar...@piuha.net 2.47% |7 | 2.00% |44270 | adr...@olddog.co.uk 2.47% |7 | 1.73% |38288 | ra...@psg.com 1.77% |5 | 1.71% |37897 | ted.le...@nominum.com 1.77% |5 | 1.47% |32493 | scott.b...@gmail.com 1.41% |4 | 1.47% |32458 | y...@checkpoint.com 1.41% |4 | 1.40% |30991 | christian.oflahe...@gmail.com 1.41% |4 | 1.37% |30267 | l.w...@surrey.ac.uk 1.41% |4 | 1.21% |26655 | l...@netapp.com 1.41% |4 | 1.09% |24055 | ferna...@gont.com.ar 0.71% |2 | 1.77% |39031 | cb.li...@gmail.com 1.41% |4 | 1.04% |22973 | to...@isi.edu 1.06% |3 | 1.18% |26094 | jab...@hopcount.ca 0.71% |2 | 1.45% |32059 | h...@cs.columbia.edu 0.71% |2 | 1.31% |28905 | rumbi...@gmail.com 1.06% |3 | 0.93% |20651 | m...@mnot.net 0.71% |2 | 1.18% |26191 | ted.i...@gmail.com 1.06% |3 | 0.76% |16908 | paul.hoff...@vpnc.org 1.06% |3 | 0.75% |16616 | do...@dougbarton.us 0.71% |2 | 1.03% |22840 | aeop...@gmail.com 0.71% |2 | 0.94% |20854 | jmp...@cisco.com 0.71% |2 | 0.91% |20202 | g...@algebras.org 0.71% |2 | 0.87% |19276 | t...@ecs.soton.ac.uk 0.71% |2 | 0.81% |17837 | sistopef...@gmail.com 0.71% |2 | 0.79% |17395 | aman...@verisign.com 0.71% |2 | 0.78% |17242 | mariainesrob...@googlemail.com 0.71% |2 | 0.78% |17142 | nar...@us.ibm.com 0.71% |2 | 0.72% |15959 | mcr+i...@sandelman.ca 0.71% |2 | 0.69% |15241 | f...@cisco.com 0.71% |2 | 0.68% |15102 | l...@pi.nu 0.71% |2 | 0.65% |14361 | lber...@labn.net 0.71% |2 | 0.64% |14208 | np...@lca.org.ls 0.71% |2 | 0.64% |14122 | alejandroacostaal...@gmail.com 0.71% |2 | 0.64% |14066 | randy_pres...@mindspring.com 0.71% |2 | 0.62% |13706 | brian.e.carpen...@gmail.com 0.71% |2 | 0.60% |13351 | p...@frobbit.se 0.71% |2 | 0.60% |13325 | d3e...@gmail.com 0.71% |2 | 0.58% |12859 | sm+i...@elandsys.com 0.71% |2 | 0.56% |12400 | stpe...@stpeter.im 0.35% |1 | 0.90% |19792 | rogag...@cisco.com 0.71% |2 | 0.53% |11788 | swm...@swm.pp.se 0.71% |2 | 0.53% |11742 | a...@anvilwalrusden.com 0.35% |1 | 0.85% |18711 | war...@kumari.net 0.35% |1 | 0.84% |18507 | ya...@cnnic.cn 0.35% |1 | 0.69% |15151 | me...@globetel.com.ph 0.35% |1 | 0.59% |13137 | ron.even@gmail.com 0.35% |1 | 0.59% |13110 | hannes.tschofe...@gmx.net 0.35% |1 | 0.59% |12940 | a...@yumaworks.com 0.35% |1 | 0.53% |11618 | stbry...@cisco.com 0.35% |1 | 0.50% |11052 | yi.ji...@gmail.com 0.35% |1 | 0.48% |10556 | jgu...@csc.com 0.35% |1 | 0.45% |10043 | vinay...@gmail.com 0.35% |1 | 0.43% | 9556 | daedu...@btconnect.com 0.35% |1 | 0.43% | 9519 | stephen.farr...@cs.tcd.ie 0.35% |1 | 0.40% | 8855 | jiangsh...@huawei.com 0.35% |1 | 0.40% | 8845 | morei...@nic.br 0.35% |1 | 0.38% | 8490 | ebur...@standardstrack.com 0.35% |1 | 0.38% | 8360 | rsouza@gmail.com 0.35% |1 | 0.37% | 8092 | bmann...@isi.edu 0.35% |1 | 0.36% | 7895 | droma...@avaya.com 0.35% |1 | 0.35% | 7799 | ma...@isc.org 0.35% |1 | 0.34% | 7595 | tnad...@lucidvision.com 0.35% |1 | 0.34% | 7555 | ptha...@broadcom.com 0.35% |1 | 0.33% | 7406 | o...@cisco.com 0.35% |1 | 0.33% | 7386 | doug.mtv...@gmail.com 0.35% |1 | 0.33% | 7316 | d...@cridland.net 0.35% |1 | 0.29% | 6466 | spen...@wonderhamster.org 0.35% |1 | 0.29% | 6439 | fg...@si6networks.com 0.35% |1 | 0.29% | 6435 | carlosm3...@gmail.com 0.35% |1 | 0.29% | 6383 | hsan...@isdg.net 0.35% |1 | 0.28% | 6274 | b...@nostrum.com 0.35% |1 | 0.28% | 6247 | j...@joelhalpern.com 0.35% |1 | 0.2
Re: "Fixing: the standards track or RFC series (was: Re: What do we mean when we standardize something?)
On 5/30/13, John C Klensin wrote: > difficult problems arise when someone comes to us with a spec > that might be ok but isn't how we would do it and tries to say > "you can have this and we will turn over change control as long > as you don't really want to make any changes". When a statement > equivalent to that is justified on the basis of either being in > a hurry or not invalidating existing implementations, we find > ourselves in the middle of the contradiction between "consensus > of industry practice" and "best engineering solution" for > standardization. If the standards proposed are reviewed well I don't think there will be contradiction, I don't recommending always sticking to best engineering solutions, because it is difficult to guarantee best solutions in present/future (best practices ok). For industry request work, IMO its better that our standards get into between *best engineering practices* and *good engineering practices*, that will not contradict with *consensus* and *industry practices*. AB
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: What do we mean when we standardize something?
Hi John, At 10:23 29-05-2013, John C Klensin wrote: The IETF has traditionally chosen the first model and a great deal of our thinking and public rhetoric are based on it. Even when we have adopted proposals, sometimes implemented ones, from elsewhere, we have insisted on change control and usually taken that seriously. One could claim that an adaptation of the second model would make the Internet more uniform, but a consensus of existing practice cannot aspire to "working better" except in the narrow sense of substitutability of conforming products. The note is thoughtful. It's the first time I see a message where the "working better" angle is discussed. If we are not going to move significantly in the direction of "consensus of industry practice", then it seems to me that we need to be careful about the arguments that are made (or at least those that are considered legitimate) in support of advancement into or on the standards track. If the IETF were to move in the direction of "consensus of industry practice" it would be moving towards consensus of industry practice based on the opinions of people in the industry who are active in the IETF. Michael Richardson asked the following question: "Given that the [Country X] mandated them, why wasn't the IETF involved earlier? The regulator really should have reached out to the IETF here. If people from Country X do not come to the IETF with the problem the IETF won't know about the problem. If people from Country X do not provide input about their industry practice the IETF will know about it. For example, if we agree on a relaxed registration procedure for some protocol parameters, it is not reasonable to later turn around and ask that that those parameters be standardized, unchanged, because they are already registered (and maybe deployed). For standardization, the IETF generally needs not only change control but an opportunity to comment on and affect the actual design and specification of whatever is being standardized. Country X would also have to allow the IETF to have change control on the specification or else it is like asking the IETF to rubber-stamp the specification. If I am not mistaken the relaxed registration procedure is so that there can be a registry of what is being used on the Internet. The difference here is that the IETF does not review the design, or it may set some minimal criteria for the review before allocating the code point. Similarly, we sometimes hear it argued that we should accept a specification for Proposed Standard unchanged because it has been extensively developed and reviewed elsewhere. That may be reasonable in some cases although I'd hope we wouldn't make it a common practice. But, if a specification adopted for Proposed Standard on that basis is then proposed for advancement to Internet Standard, I think the review should be comprehensive --perhaps even more comprehensive than the usual such review-- because the Internet Standard is unambiguously an IETF product and recommendation not that of the other body. If we allow a specification to advance to Proposed Standard without an open and critical review because it was developed and reviewed comprehensively by outside expert organizations and then allow the Last Call review for Internet Standard to be constrained by existing deployment, we would have gone into the rubber stamping business that we regularly say is incompatible with our standardization model. That doesn't mean, of course, that changes during review for Internet Standard are likely to be a good idea. Those who propose changes to the spec, and especially to the protocol, should have to convince the community that those changes are important enough to overcome the costs, including those of incompatibility with deployed versions. But I don't think we can reasonably exclude them from raising the issues and making those arguments. If an intended Proposed Standard has actually been developed and reviewed elsewhere the Last Call and IESG Evaluation is not a problem, i.e. any problem in the specification has already been identified and addressed. One of the issues here is the rhetoric (the undue use of exaggeration, or from an IETF perspective, making unpleasant comments to discourage people from identifying problems). It is difficult to have an open and critical review of an Internet Standard. There is a significant cost for any change made at that level as it may cause interoperability issues. What "we" mean when we standardize something is that "we" will think carefully before making a change as "we" would like the specification to be stable even if that means not fixing some minor errors. Internet Standard could have been used to say "we" are not going to tinker with this specification and it is your best bet if you want to deploy the code and forget about it for a few years. As an unrelated comment, what could "we" mean? It could mean:
Re: When to adopt a WG I-D
> > To be honest at this point I'm sort of reflexively > > anti-process-documents, unless there's an actual problem > > that needs actual solution. > Which is why this isn't a process document. Watching this thread, I sense the authors trying hard not to make a process document, presumably because that would be hard, contentious, low probability of success, or something. But this idea that this ID is just a random collection of thoughts that folk might find interesting and therefore is informative is also pretty silly. Melinda has it right. First decide on what problem you are solving. If you can't do that, no solution (or document) will be satisfactory. IMO, this document absolutely needs to be a "process" document if it is to have any value. It is presumably trying to collect experience and wisdom. Presumably folk should make use of that experience and wisdom. If that is not a best practices document, what is? If this document doesn't provide guidance, in the "should" sense, with an explanation of why a particular practice makes sense and what can go wrong if that advice is not followed... then what good is it? > The origin is a WG chairs Edu session. Turns out there was not a lot > of clarity among a bunch of WG chairs about what they did and > why. My assumption is that if the chairs needed some time to > discuss this, the community might need that as well. If this document is clarifying, isn't that "updating" an existing document and charting new ground? I.e, how can this not be normative? > NOTE:This draft is intentionally non-normative. It is meant as a > guide to common practice, rather than as a formal definition of > what is permissible. What is the difference between a "guide to common practice" and a BCP? Is attempting to find a difference a case of hair splitting? Thomas
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: When to adopt a WG I-D
On May 29, 2013, at 11:53 PM, Adrian Farrel wrote: > I can also see potential for adding some info to the Tao, but the danger > there is that document becomes too big and too detailed to be of use. Many would claim it already is. We discussed that here a few years ago, and informally decided "too long" was better than "too short and with a lot of pointers to other documents that needed to be read". > Is this a tutorial? Mainly. To quote... NOTE:This draft is intentionally non-normative. It is meant as a guide to common practice, rather than as a formal definition of what is permissible. Proposal: maybe don't do this as an Internet Draft, but do it as a tutorial. --Paul Hoffman
Re: When to adopt a WG I-D
>> Yes, I'm sure. >> Your turn now. >> Are you sure? > No, not at all. did you somehow miss the pdu data formats and exchange ladder diagram? if this is not a process document, then what the heck is it, chopped liver? randy
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: Last Call: (Resource R ecords for EUI-48 and EUI-64 Addresses in the DNS) to Proposed Standard
> "Joe" == Joe Abley writes: >> Okay, I felt a bit embarrassed about having said this, so I went >> back and reviewed the justification for bringing this forth as an >> IETF document. The stated reason for publishing the document as >> an IETF document is that there is a regulatory requirement in >> Canada to implement something like this. Joe> No, that's not right (and really, if that's how you read the Joe> document at hand then clearly I need to re-write it). Let's Joe> review. Joe> The original motivation for requesting code-point assignments Joe> for new RRTypes which would facilitate a clean encoding of Joe> EUI-48 and EUI-64 addresses in the DNS resulted from my Joe> distaste for the evident lack of consistency in approach taken Joe> in response to the CRTC's general requirement that cable Joe> operators publish this kind of data in the DNS, for internal, Joe> authenticated access by resellers of their access networks in Joe> Canada. okay, fair enough. Given that the CRTC mandated them, why wasn't the IETF involved earlier? The regulator really should have reached out to the IETF here. I'll be the first to swear at my government for continuing to have ISO think here. This seems like a place for the IAB to respond to this regulator, and in this case, point towards your document and ask why there isn't someone from the regulator speaking for this. Joe> It's not at all certain or even likely that the CRTC-mandated Joe> systems will ever use these RRTypes. That ship has surely Joe> sailed. The reason for requesting the code-points was to make Joe> future such situations less messy, and more likely to result in Joe> DNS schemas (if that's a phrase) that were consistent and Joe> parseable. Then that's even more a reason for the IAB to send the CRTC a letter. Maybe it's time for a Canadian liason (but then every country will want one...?), or maybe it is time for a "regulatory liason" to be created... I dunno. Joe> I've had feedback from a small number of people who are already Joe> in the habit of publishing MAC addresses in the DNS as part of Joe> (as I understand it) inventory management and internal Joe> troubleshooting. I take no position here on whether that's a Joe> good idea, but I conclude that publishing such data in the DNS Joe> happens today, regardless of the availability of the EUI48 or Joe> EUI64 RRTypes. Did they like the scheme? Joe> In my mind, this suggests publication of the spec in the RFC Joe> series, where it can join other specifications for the encoding Joe> of IPv4, IPv6, NSAP, E.164, X.25, ISDN, ATM, NIMROD, HIP, and Joe> ILNP addresses. I may have missed some. I agree. -- Michael Richardson , Sandelman Software Works pgpTwzShflCa9.pgp Description: PGP signature
Re: Participation per Region of Authoring IETF documents vs Marketing
On May 30, 2013, at 2:45 AM, Mark Nottingham wrote: > I would take those numbers with a HUGE grain of salt (as Jari documents). I appreciate Jari's effort and use his page extensively. However, I agree taht geography data should be taken with a grain of salt. In my case I created several document while living in South America but moved to Europe just before the RFC was published with my current european address. So, even if I worked on it for 3+ years from LATAM, those document show me as european. You also have to consider all the native people from one region that move to another one. My proposal to the "diversity working group" was to add a request from the RFC editor to the authors to establish the geography they would like to be associated with and add that information to the document metadata at publication time. If we want to tackle the cause of this problem and not the consequences, we need to look at the macro-economical issues mentioned by Joel. That said, I am optimistic that we will see improvements sooner than later thanks to new research/development centres been established in LATAM but these processes take time. Referring to what the impact of hosting a meeting in LATAM would have on participation, we need to consider that IETF meetings are not conference but working meeting. We get there (or online) to get work done. Presentations last only around 5-10 mins they are not marketing-sexy and they normally start with "difference from last meeting". What I want to say is that engagement needs to happen much earlier and while having a meeting in a location will always have a positive effect on local participation (as stated by Michael), we need to set expectations right. Personally, I believe we should spend more energies from now to that date working on mentoring and improving the fellowship program. I was involved in the first 3 years of the program and I recommended the creation of the "recurrent" fellows (initially fellows could only attend one meeting). Although I am still in contact with my past mentees, I think there is still room for improvement and we could think on a long-distance volunteering program. Referring to the chosen location (Buenos Aires), I think it is an excellent choice from the point of view of our traditional requirements to get job done. However, the comments about the current exchange and import limitations are relevant and should be evaluated by the IAOC when establish the current risks or running the meeting there from an operational perspective. Typical business operations such as the possibility of charging local sponsorships or local attendees in USD, been able to wire the hotel IETF fees back to the US in USD (and at a reasonable exchange rate) or importing devices to run the meeting should not be taking for granted but should be discussed with our local contact. Roque > For example, I've lived in Australia since 2006, and yet am only listed as > producing RFCs in the USA. > > Regards, > > > On 30/05/2013, at 10:39 AM, Abdussalam Baryun > wrote: > >> Hi Lars, >> >> It was for Asia region, I thought its rate is between (5 - 50) >> rfc/year for last 3 years. Basing on; The first figure of RFCs is the >> Comparison of countries over the year [1], the second, is the >> Distribution of number of RFCs per continent [2], the third is >> publication rate per year [3]. For the I-Ds going in IETF is seen from >> the distribution of drafts according to the countries of their authors >> [4] and [5]. All figures make together the below conclusions, even >> though some of them need more details for readers to understand. >> >> As from Figure [1] always one region (North America) is doing about >> 200 rfc/year and the each of others may do between 5 - 50 rfc/year or >> 50-100, but all together other regions do 150 rfc/year, so total >> ietf-participation can be about 350 rfc/year. The Figure [2] is not >> reasonable, not showing of years or period of such numbers. >> >> So my understanding is that for Europe-region and Asia-region, the >> number of I-Ds rates are high compared to North America, but not the >> rate of RFCs. I see that the total RFCs ietf-output rate (RFC/year) as >> in Figure [3] for the last three years is about 350 rfc/year, so if >> North America is having 200, the all others only will have about 150 >> rfc/year. The total RFCs produced per countries is in Figure [6] is >> reasonable but if compared with Figure [2] I get lost. >> >> From Figure [5] (also [4]) the number of I-Ds (now currently 2013 >> outstanding) from Asia and Europe are about 600 and 1200 respectively >> (let us add them up so =1800 ids), which I think only about 150 will >> succeed (non-North America drafts). Furthermore, for North America the >> I-Ds are 1500 ids and only 200 ids will succeed to become RFCs. I >> think that Asia and Europe should have together about 250/year rfc not >> 150 rfc/year. If we do more MARKETING effort
Re: Last Call: (Resource R ecords for EUI-48 and EUI-64 Addresses in the DNS) to Proposed Standard
At 15:21 29-05-2013, Ted Lemon wrote: I didn't say that I support the draft; just what I think could be done to somewhat mitigate its scope. My personal (non-hat) feeling about the draft is that if there is I did not read those messages as meaning that you support the draft or that there was anything negative. At 18:34 29-05-2013, Joe Abley wrote: The original motivation for requesting code-point assignments for new RRTypes which would facilitate a clean encoding of EUI-48 and EUI-64 addresses in the DNS resulted from my distaste for the evident lack of consistency in approach taken in response to the CRTC's general requirement that cable operators publish this kind of data in the DNS, for internal, authenticated access by resellers of their access networks in Canada. It's not at all certain or even likely that the CRTC-mandated systems will ever use these RRTypes. That ship has surely sailed. The reason for requesting the code-points was to make future such situations less messy, and more likely to result in DNS schemas (if that's a phrase) that were consistent and parseable. Code-points were assigned following the documented process, which relies upon expert review. To support that review, I wrote a specification for their use as an I-D (intended status: experimental). Note that by specification I mean a technical description of the encoding and protocol considerations associated with EUI48 and EUI64, and not any kind of applicability statement or guidance for how the RRTypes should be used. I've had feedback from a small number of people who are already in the habit of publishing MAC addresses in the DNS as part of (as I understand it) inventory management and internal troubleshooting. I take no position here on whether that's a good idea, but I conclude that publishing such data in the DNS happens today, regardless of the availability of the EUI48 or EUI64 RRTypes. The new RRTypes have since been implemented in the code base of BIND9, NSD, Knot DNS and PowerDNS based on that specification. After some discussion in dnsext, directly with individual contributors and with Joel as Ops Area AD, the draft was revised. Text was added, including the general use case for storage of this data in the DNS mandated by the CRTC (requested by Joel). The intended status was changed to standards track, since I was told that made sense. After last-call discussions on this list the intended status was changed to informational, and more textual changes were made. The stated reason for publishing this draft in the RFC series (I'm stating it now!) is that the RFC series is the most obvious place for anybody to look for a specification about the implementation of these RRTypes. That's it. The above is what I understood. So, in summary: 1. There is, I would suggest, a stable specification. 2. Code points are assigned. 3. There are multiple implementations. 4. There are multiple use-cases, and multiple examples of these data types being published in the DNS today (note, I am not suggesting that widespread use is likely or sensible.) 5. It would be useful (I would assert) that the specification can actually be found by people in the future who care about it. In my mind, this suggests publication of the spec in the RFC series, where it can join other specifications for the encoding of IPv4, IPv6, NSAP, E.164, X.25, ISDN, ATM, NIMROD, HIP, and ILNP addresses. I may have missed some. There was once a case of a specification which had seven implementations and the publication path hit the IETF heavy tail. In the current case publication has been requested in the IETF Stream. There are some differences between the IETF Stream and other Streams (in my opinion). On a different thread and obviously in a different context John Klensin mentioned that: "For example, if we agree on a relaxed registration procedure for some protocol parameters, it is not reasonable to later turn around and ask that that those parameters be standardized, unchanged, because they are already registered (and maybe deployed). For standardization, the IETF generally needs not only change control but an opportunity to comment on and affect the actual design and specification of whatever is being standardized." RFC 6895 was reviewed by the IETF community. RFC 6195 was reviewed by the IETF community. I won't claim that I did not read them or that I did not have the time to review and comment about the proposals. How does privacy fit into all this? Well, that's what the IAB has been talking about. The following objection was posted to the mailing list: "- The IETF, an international standards body, believes itself to be the wrong forum for designing protocol or equipment features that address needs arising from the laws of individual countries, because these laws vary widely across the areas that IETF standards are deployed in.
Re: When to adopt a WG I-D
On 5/30/2013 9:58 AM, Melinda Shore wrote: On 5/29/13 11:56 PM, Adrian Farrel wrote: Yes, I'm sure. Your turn now. Are you sure? No, not at all. Let me try to help... A process document is a normative statement of structure and sequence for a process. It is the organization's means of saying how things must be done. That 'must' might include degrees of freedom, of course, but they key point is that whatever it specifies has formal authority within the organization. The current draft is quite explicitly not that. The current draft is a kindly mentor, sitting around the bar, imparting sage advice for how something can be reasonably done, within the formal bounds of IETF rules and culture. It's only 'force' is whatever credibility the individual reader choose to assign to the text, as is true for any "Informational" RFC... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: When to adopt a WG I-D
On 5/29/13 11:56 PM, Adrian Farrel wrote: > Yes, I'm sure. > Your turn now. > Are you sure? No, not at all. Melinda
RE: When to adopt a WG I-D
> > Which is why this isn't a process document. > > Are you sure? Oooh, a quiz. I like quizzes. Let me see. Yes or no. Hmmm. Yes, I'm sure. Your turn now. Are you sure? Ciao, Adrian
Re: When to adopt a WG I-D
On 5/30/2013 9:06 AM, Melinda Shore wrote: On 5/29/13 10:53 PM, Adrian Farrel wrote: I see a wedge :-) The problem is where to stop. Well, I don't know. Maybe the problem is where to start. That is to say, I don't know what problem this document is trying to solve, or if there even is a problem. Like you, I think we need to be very careful about creating stray process documents or... stray processes. That said, we have processes and we need to do them well. The IETF permits an extraordinary degree of flexibility in much of the detail for doing the actual work. The main benefit is that it lets a group adjust its style of work according to the nature of the work and the preferences of the workers. A small, well-integrated group that is focusing on a narrow, well-understood topic can reasonably use a very different daily style than a large, highly heterogeneous group that is working on a difficult, poorly understood topic. Currently, that tends to mean that folk invent things on the fly, often importing models from other groups. Both the spontaneous invention and the importation risk assorted problems ranging from serious inefficiency to outright mismatch with the culture. What we've lacked is much effort to capture 25+ years of experience of doing the grunt work of IETF daily management. We don't really pass on the culture very well, beyond some clever catch phrases and formal process structure and criteria specifications. So the intent of the current draft is to capture one aspect of the collective wisdom and pass it on to others. It is "us" -- all of us -- speaking to "them", as if sitting around the bar, talking about how to get things done. The document is quite explicit that it has no force other than representing some collective wisdom. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: When to adopt a WG I-D
On 5/29/13 11:16 PM, Adrian Farrel wrote: > Which is why this isn't a process document. Are you sure? Melinda
RE: When to adopt a WG I-D
Hi Melinda, Funny, but I agree. > To be honest at this point I'm sort of reflexively > anti-process-documents, unless there's an actual problem > that needs actual solution. Which is why this isn't a process document. The origin is a WG chairs Edu session. Turns out there was not a lot of clarity among a bunch of WG chairs about what they did and why. My assumption is that if the chairs needed some time to discuss this, the community might need that as well. The problem I am now hearing is that "the document lifecycle is not described coherently in one place." That wasn't the problem I was aiming to solve, but maybe enough others consider it is a problem. > Is this a tutorial? Mainly. To quote... NOTE:This draft is intentionally non-normative. It is meant as a guide to common practice, rather than as a formal definition of what is permissible. Adrian
Aw: What do we mean when we standardize something?
Hi John, this is a great summary. Regarding the question about the type of standardization we want I would argue for a mixture of both since in practice there are, of course, a lot of grey areas. I suspect that setting the expectations right at the beginning of starting the work (in a group or on a specific document) are important. I guess it is just the "surprises" that folks get concerned about when they suddenly realize that the last call period isn't actually something were they can change a lot (even if they dislike something) because the technology is widely deployed already and any change in the spec is likely going to cause a disconnect with the deployment. Ciao Hannes Gesendet: Mittwoch, 29. Mai 2013 um 19:23 Uhr Von: "John C Klensin" An: ietf@ietf.org Betreff: What do we mean when we standardize something? Hi. A number of recent discussions, specifically including the Last Calls on DKIM and standardizing RRTYPEs and even to some extent the meeting location ones, have started me thinking that perhaps we need to review what business the IETF is actually in and to be sure that we actually still agree about it. The note that follows is an attempt to take the isolated parts (and symptoms) of that discussion up a level and discuss it as a general issue. The key issues go to the very nature of standardization. While there are many variations on each, there are two fundamentally different models for what standards are about. Each is legitimate in its own way and each has its advocates, but they are different. One is a focus on quality: an engineering consensus on the best technical solution given physics or consensus goals and boundary conditions. The other is sometimes called "consensus of industry practice" in which a standard reflects what is already deployed, possibly picking among different implemented options in a few cases but mostly requiring that a common model appears before standards are issued. Two variations on the second theme were extremely common in the earlier days of computer and telecommunciations standardization but are less popular today (at least in theory) due to IPR and antitrust concerns. Both start with a single vendor (or closed consortium) implementation. That implementation might then be offered for standardization (sometimes with a "no major changes" restriction) and adopted more generally or endorsed by traditional SDOs. Or that single implementation might be reverse-engineered by others and then the result treated as common industry practice. Despite the occasional claim that a strange (to me) idea called "anticipatory standardization" is a variation on the second model, that combination makes standards in the absence of, or prior to, implementation and deployment an impossible contradiction. It is basically incompatible with innovation of any type. The IETF has traditionally chosen the first model and a great deal of our thinking and public rhetoric are based on it. Even when we have adopted proposals, sometimes implemented ones, from elsewhere, we have insisted on change control and usually taken that seriously. One could claim that an adaptation of the second model would make the Internet more uniform, but a consensus of existing practice cannot aspire to "working better" except in the narrow sense of substitutability of conforming products. It is interesting that the multi-stage model of RFC 2026 (particularly the original "Proposed Standard" definition), the IEEE's "Trial-Use" standards (the current Section 5.7 of their Standards Board Operations Manual, http://standards.ieee.org/develop/policies/opman/sect5.html#5.7, makes instructive reading), and ISO "Technical Specification" all try to combine the two models by allowing a preliminary specification --one that is intended for trial implementation but not deployment-- to be designed on an engineering basis and then standardized only when implementations exist and can be compared (our original "Draft Standard"). In theory, only when both an industry common practice and consensus about value emerges does true standardization (including our original definition for "Internet Standard") move forward. We know how well that has worked for us in practice. While there have been exceptions, I don't believe it has worked much better for other SDOs. If we are not going to move significantly in the direction of "consensus of industry practice", then it seems to me that we need to be careful about the arguments that are made (or at least those that are considered legitimate) in support of advancement into or on the standards track. For example, if we agree on a relaxed registration procedure for some protocol parameters, it is not reasonable to later turn around and ask that that those parameters be standardized, unchanged, because they are already registered (and maybe deployed). For standardization, the IETF generally needs not only change control but an opportunity to comment on and affect the actual
Re: Participation per Region of Authoring IETF documents vs Marketing
Thanks :) On 30/05/2013, at 5:06 PM, Jari Arkko wrote: > > Mark: > >> I would take those numbers with a HUGE grain of salt (as Jari documents). > > Indeed > >> For example, I've lived in Australia since 2006, and yet am only listed as >> producing RFCs in the USA. > > My apologies. I added a data item to recognise you… > > Jari > -- Mark Nottingham http://www.mnot.net/
Re: When to adopt a WG I-D
On 5/29/13 10:53 PM, Adrian Farrel wrote: > I see a wedge :-) > The problem is where to stop. Well, I don't know. Maybe the problem is where to start. That is to say, I don't know what problem this document is trying to solve, or if there even is a problem. I know that we've had some major document quality issues in opsawg and Benoit has provided some needed guidance on document adoption, but this doesn't seem to be dealing with that sort of issue. Is it that people are confused about when to adopt a document (or not)? Is this intended to provide some sort of context to resolve complaints? Is this a tutorial? To be honest at this point I'm sort of reflexively anti-process-documents, unless there's an actual problem that needs actual solution. Melinda
Re: Participation per Region of Authoring IETF documents vs Marketing
Mark: > I would take those numbers with a HUGE grain of salt (as Jari documents). Indeed > For example, I've lived in Australia since 2006, and yet am only listed as > producing RFCs in the USA. My apologies. I added a data item to recognise you… Jari
