Subject: Re: Issues in wider geographic participation

From: John C Klensin <[email-masked]>
Date: Thu, 30 May 2013 02:04:54 -0400

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 meeting in a
single location.  Probably holding a whole year or two of
meetings in the same general vicinity wouldn't make any
significant difference either, at least after we moved on.  

Borrowing from some of the discussions about mentoring during
and after IETF 86, I suggest that, if we really want to
encourage active participation from places where we now have
very little, we would:

(i) Try to increase awareness of the IETF and what it does in
those areas, via ISOC chapters, lectures, and other forms of
contact.  Variations on this have been suggested by others.
Note that doing this for a given location would require putting,
at most, one or two people on airplanes (possibly at IETF or
ISOC expense), not order 1000 of us at individual or company
expense.  (See George Michaelson's most recent note in the "IETF
Meeting in South America" thread.)

(ii) Try to assign a document process advisor to each newcomer
the first time that person posts an I-D (or earlier if we can
determine that an I-D is in progress or should be generated from
other discussions).  This is a little different from a mentor
(see Iiii)) in that the role would be to specifically advise on
the process of getting a document through the system, what
obstacles are likely to be encountered, etc., and could be
pretty aggressive if that were necessary.   The process advisor
could recommend that that author seek out other resources,
including a mentor or editorial help, when necessary.  The
IETF's curmudgeon component, many of whom would make lousy
mentors, might still be good document process advisors.

(iii) Allow new participants who intend to participate remotely
and by mailing list to request and be assigned mentors, ideally
mentors who speak the participant's primary language.  Focusing
our efforts only on people who show up at meetings means that we
leave the folks who could be among our more productive
participants in the cold and, for most regions where we have
little penetration and resources are a problem, pretty much
guarantees that it will stay that way.

(iv) Encourage ISOC to redesign the IETF Fellows program so that
people who were reasonable candidates for long-term
participation were tracked differently from the
observer-tourists.   In the potential participant track, the
assumption should be that Fellows might have participated
remotely (including by mailing list) already, that such
participation would give a candidate Fellow some extra priority
or points in the selection process, and that activities during
IETF should include explicit and focused discussions of optimal
ways to participate without attending meetings.  If we (or ISOC,
or other organizations) later get the Fellows to more meetings,
that would be great, but the goal should be to make a good
remote participant, not people who can be effective only if they
attend a lot of face to face meetings.

The above would not be easy.  It would require a large number of
experienced members of the community to make a major commitment
to working with new authors and non-attendee newcomers.  But it
would help significantly to bridge the gap between "interested
in the IETF and its work" and "contributing participant".
Flying a thousand person-weeks worth of folks into an area where
we have little participation and attracting a few local tourists
won't have the same effect --with or without a few hours of
"newcomer" sessions-- and will still leave people with the need
to make that transition if they are going to be effective.

best,
    john

---

From: Randy Bush <[email-masked]>
Date: Thu, 30 May 2013 06:30:55 -0700

> 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

---

From: John C Klensin <[email-masked]>
Date: Thu, 30 May 2013 13:24:30 -0400

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
<[email-masked]> wrote:

> --On Thursday, May 30, 2013 08:03 +0000 "Eliot Lear (elear)"
> <[email-masked]> 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
<[email-masked]> 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 is a broad solution to a broad class of
problems.  But I think it would increase opportunities for
quality reviews and would allow some relevant people
--especially from areas with little IETF involvement-- to help
themselves and us out without signing up for "IETF
participation".  If we could then suck them in gradually, so
much the better.

Finally, fwiw, I wasn't part of the discussions that created the
IETF (I was "getting out" into some work that did not involve
Internet protocol design but that definitely involved
resource-poor communities), so I can't judge whether "The IETF
was formed in part to have rapid impact".  But, to the extent to
which it is the case, I think we gave up any claim we had to
needing to shortcut either reviews or openness in the interest
of speed when our minimum time to get almost anything
standards-related done passed a year and kept climbing.   YMMD,
of course.

    best,
    john

---

From: Warren Kumari <[email-masked]>
Date: Thu, 30 May 2013 15:31:19 -0400

>> 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 exercises, meet a few times, and then finally publish a document, a set of folk implemented a few alternate solutions in the real world, got some useful understanding of what works and what doesn't, iterated, and moved on to other things. Sure, we chairs could have moved thing along faster, but the IETF cycles *is* long.

2: Ivory towerism / academics.
"The work that the IETF is doing is not actually relevant to what I need."
A large number of drafts don't really explain what issue they are trying to address (poor problem statement) and / or are trying to address issues that don't actually exist in the real world. Often drafts try to address an issue that only exists in one small corner case on one participant's network, or issues that *used* to be important, but have now becomes less so as networks have evolved.

The DHCPv6 discussions spring to mind here -- the IETF view (hey,  I mentioned generalization above!)  on DHCP / SLAAC were grounded in one view of how the world worked / elegance, but the operator's view was that they simply wanted something that works like it does in V4.

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.

Many of the drafts written are either being pushed for commercial reasons, or because it is someone's pet project, not because they solve a critical issue for others.
Randy's article on "Testing Spaghetti — A Wall’s Point of View" (http://archive.psg.com/051000.sigcomm-ivtf.pdf) speaks mainly to the commercial interests, but Jon also had this to say:
"It's perfectly appropriate to be upset. I thought of it in a slightly different way--like a space that we were exploring and, in the early days, we figured out this consistent path through the space: IP, TCP, and so on. What's been happening over the last few years is that the IETF is filling the rest of the space with every alternative approach, not necessarily any better. Every possible alternative is now being written down. And it's not useful."
I know that I for one am guilty of this -- I wrote and have been slowly pushing a draft on Omniscient AS112 servers (draft-wkumari-dnsop-omniscient-as112) -- this is by far not the most important issue in DNS, nor in the Internet. It *does* solve an (IMO) important issue, but there are more important issues that *should* be worked on -- this one however is interesting / important *to me*, and so that's where I spent some cycles. 

3: I have real work to do -- I simply don't have the cycles to read a few thousand mails about some tiny unimportant detail.
This is related to items 1 and 2. 
Related to this is the fact that most operators can only justify attending a small number of conferences -- attending 3 IETFs and 3 NANOG / RIPE / whatever is simply too much.
 
I don't really know if this is an problems that can (or should) be solved. Often operators are more pragmatic than IETF folk, and simply want a good solution, not necessarily a perfect solution. "The perfect is the enemy of the good" -- this often leads is to create a solutions that is overly complex,  and / or solves a problem too late…
This is (IMO) a cultural difference / an artifact that protocol design *needs* more precision / rigor than operations, as it is much harder to change once baked.

4: I tried participating, but I got ignored / attacked.
Unfortunately I think that this is one of the bigger cultural issues, and one of the harder ones to address. 
The IETF is in many ways a debating society -- you present an idea / draft, and folk challenge (in what could often be interpreted as a confrontational manner) what you've said.
This is simply part, and a much needed part, of the IETF culture -- if you've said something and no-one is challenging it, chances are is was not very interesting / novel. The purpose of saying something in the IETF context (should be) to get critical feedback so you can improve it. 
If, however, you are not expecting this / are not used to it, this interaction can come across as rude  / antagonistic. Folk can feel as though they are being attacked personally, and not simply being presented with an opportunity to better explain their ideas / improve them. 
I realize that this is all touchy-feely / some folk will think that everyone just needs to wear their big boy pants, but if you are willing to take a step back and consider how different cultures interpret interactions…

There are some other cultural issues at play here.
I have seen instances where an operator comes along to try and participate, but doesn't understand that, while they have credibility / standing in their own community, they are an unknown entity in the IETF community. When entering a new community one needs to learn the norms, and it takes time to establish your reputation / credibility. This can lead to frustration with item 4.

A large number of IETF participants are also senior within their organizations, and migrated up though operations to their current position, often managing operates along the way. Sometimes it is hard to admit to oneself that one has lost touch with one's roots, and so operates can come across as "upstarts" and be looked down upon by IETF participants. This causes friction.
This is partly reflected in some of the discussions one hears in threads like this / general hallway discussions -- we often hear about how the IETF would like more operators to be involved / attend, but one very seldom hears IETF participants trying to become more involved in operations / participate in their local NOGs, etc.

Anyway, these are simply my (much simplified) views on a complex topic, much more complex than can be easily captured in a single mail. But somebody is demanding their soapbox back, so I will end here.

W

--
Don't be impressed with unintelligible stuff said condescendingly.
    -- Radia Perlman.

---

From: John C Klensin <[email-masked]>
Date: Thu, 30 May 2013 20:37:27 -0400

--On Thursday, May 30, 2013 15:31 -0400 Warren Kumari
<[email-masked]> 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

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 31 May 2013 02:19:06 +0100

Hi,

This thread is helpful to me.

> but the operators are ultimately the folks who pay the vendor's

I agree so far.

But who pays the operators' bills, and do we need to encourage participation at
that level as well?

Adrian

---

From: Melinda Shore <[email-masked]>
Date: Thu, 30 May 2013 18:08:58 -0800

> but the operators are ultimately the folks who pay the vendor's

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

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 30 May 2013 19:20:15 -0700

Hi -

> From: "Adrian Farrel" <[email-masked]>
...
> But who pays the operators' bills, and do we need to encourage participation at

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

---

From: <[email-masked]>
Date: Fri, 31 May 2013 03:21:56 +0100

Melinda Shore, all at sea:
> 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/

---

From: Melinda Shore <[email-masked]>
Date: Thu, 30 May 2013 18:41:22 -0800

> 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

---

From: Douglas Otis <[email-masked]>
Date: Thu, 30 May 2013 19:52:48 -0700

> 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

---

From: Abdussalam Baryun <[email-masked]>
Date: Fri, 31 May 2013 08:36:00 +0200

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,

> that doesn't lie easily within IETF scope... and probably

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.

> Chapter structure is at least making useful contributions in the

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.

> 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

Let's make IETF give opportunity to all parts (mentioned in its
mission statement) to participate,

> affected whose day-to-day technology is a decade or two behind

I agree, but I prefare to say all areas of work need geographic input,
because you never know what will be needed in the future by the
Internet Community.

> experience no matter what we do about "newcomers" or recruiting).

I disagree, please read in the IETF it mentions below as open to
individuals, so why you make them must have affiliations.

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.

> increase noise without adding much to the signal.

Again, I think you maybe suggesting to change the IETF mission or the
type of participants the IETF needs.
IMHO, the Internet-community individuals are the important focus of
the IETF, so no one can become noise only if he/she gets out of
IETF-procedure. Noise is out of the system-procedure of the signal
communication, so it is noise, so your example is not correct when you
refer to IETF's diverse parts.

> significant difference either, at least after we moved on.

I disagree, please read statistics, the most participants are from
North America, and the most meetings held are in North America. I
think if we ask a business men/women of if there is an affect or not,
they will say there are affects, humans are sensitive but different
way than machines.

> ISOC expense),

I have no objection only if the new-comer agrees to such mentoring.

>not order 1000 of us at individual or company

No one is forced to attend or spend time/money, we always have remote
facilities to do the job in all IETF activities. Please read my reply
to that post of sub;meeting in South America that you refered to.

http://www.ietf.org/mail-archive/web/ietf/current/msg79765.html

> mentors, might still be good document process advisors.

Disagree, that is discriminating between participants, all
participants should be equal don't you think,

> guarantees that it will stay that way.

Again that is discrimination of focus-of-efforts, the IETF does not do
that. However, if the some new-participant agrees with that, then it
can be ok, otherwise, no. So it should be after the agreement of
participant and with no excluding if disagreed.
> attend a lot of face to face meetings.

I agree that IETF management discuss this point with ISOCs (or each
region ISOC), and each ISOC feedback should be considered as well.
>
> The above would not be easy.

Nothing is easy when it involves alot of people's lives/times/money.
However, IMO, your proposal will not be encouraging all
new-participants but maybe only yung-new-participants.

>  It would require a large number of
> to working with new authors and non-attendee newcomers.

I support this point as well, but without making new-participant feel
that he/she discriminated from others. If it is only saying you are in
level 1 of participating, fine but not saying; well you are in level 1
so please don't make noise (such behavior is not acceptable), or you
are in level 1 so no one in the community wants to know your thoughts
(such behavior is not acceptable), or you did not write an I-D so
people will not listen to you until you do, etc.

>  But it

Only if there is mutual respect and equal opportunities,

> to make that transition if they are going to be effective.

Regarding region attraction/effects, I may agree and disagree.
Agreeing because I want to meet some authors of excellent RFCs, but I
mostly disagree with the point for some reasons. Your point here is
assuming many things which are not always true. You assume that
majority of Internet-community are represented by current IETF
participation, and that if new participating they mostly may not be
affective. You assume that all IETF f2f participants are all affective
and will continue that way. You assume that other regions that are not
participating in IETF because they are not aware of the IETF. You
assume that being effective mostly-means that you have to f2f attend
meeting. You assume that new-comers will be encouraged by
special-sessions, and assume that the thousand persons need to make
transition to such region. IMHO, the IETF work and *business* is
mostly done *remotely* on its lists not in f2f meetings, but community
interconnections are done in *meetings*. Therefore recommend a Wider
Geographic Participation Diversified and not discriminated.

Please note that the above is my opinion and believe, but if the
comments are wrong, feel free to comment on them.

Regards

Abdussalam Baryun
University of Glamorgan, UK

- I worked on four new I-Ds so far and doing my best to renew them shortly.
- I never attended an IETF meeting so far, because not able to, but I
will do in future, because want to meet most of the IETF ADs which are
encouraging, and to meet some participants that done excellent RFCs.
- I beleive that I am always affective and following procedure. I am
active to remote participate in IETF business as long as no manager in
IETF informed me to stop (relating to legal procedure), or informed me
that I am out-of-procedure (with reference/reason).

---

From: Fernando Gont <[email-masked]>
Date: Fri, 31 May 2013 12:36:50 +0200

John,

> that doesn't lie easily within IETF scope... and probably

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: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Randy Bush <[email-masked]>
Date: Fri, 31 May 2013 06:34:52 -0700

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

---

From: John C Klensin <[email-masked]>
Date: Fri, 31 May 2013 12:36:03 -0400

--On Friday, May 31, 2013 12:36 +0200 Fernando Gont
<[email-masked]> wrote:

> 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

---

From: Warren Kumari <[email-masked]>
Date: Fri, 31 May 2013 14:44:02 -0400

> 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

--
The duke had a mind that ticked like a clock and, like a clock, it regularly went cuckoo.

    -- (Terry Pratchett, Wyrd Sisters)

---

From: Randy Bush <[email-masked]>
Date: Fri, 31 May 2013 12:56:41 -0700

> 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:

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

---

From: John C Klensin <[email-masked]>
Date: Fri, 31 May 2013 19:50:37 -0400

(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
<[email-masked]> 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.
> 
> 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

---

From: Randy Bush <[email-masked]>
Date: Fri, 31 May 2013 17:23:24 -0700

< 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

---

From: manning bill <[email-masked]>
Date: Fri, 31 May 2013 17:27:07 -0700

amen!  :)

> is left of the e2e internet down the drain with it.

</rant>

---

From: Warren Kumari <[email-masked]>
Date: Fri, 31 May 2013 21:13:32 -0400

On May 31, 2013, at 8:23 PM, Randy Bush <[email-masked]> wrote:

> 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,

Yup

> 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

+1.
w

---

From: Warren Kumari <[email-masked]>
Date: Fri, 31 May 2013 21:21:23 -0400

On May 31, 2013, at 3:56 PM, Randy Bush <[email-masked]> wrote:

> 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

Unfortunately not -- I had some conflict thing...

> 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

Yes. Maybe it should be designed to present the contentious bits?
W

-- 
Militant Agnostic -- I don't know and you don't either...

---

From: Masataka Ohta <[email-masked]>
Date: Sat, 01 Jun 2013 10:46:11 +0900

> 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.

 > 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

> 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.

 >> exit, ...  at least we got rid of the tla/nla classful insanity.  but

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

---

From: John C Klensin <[email-masked]>
Date: Fri, 31 May 2013 23:00:34 -0400

--On Friday, May 31, 2013 17:23 -0700 Randy Bush <[email-masked]>
wrote:

> 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

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 01 Jun 2013 16:35:45 +1200

On 01/06/2013 15:00, John C Klensin wrote:
> Ops is probably not completely right either.  

It was more complicated. I was actually running a team that ran site
network ops at the time, and (since DHCP was not yet deployable),
IPv4 was then a serious nuisance to manage, compared say to Novell
Netware and, even, Appletalk. There were good reasons we wanted
stateless auto-configuration and unlimited subnet size, to mention
two IPv6 bells and whistles. If DHCP had already been deployed,
our opinion might have been different.

> For example, with
> fundamental and important features of the Internet.  

It turns out that as soon as you envisage a network in which some
nodes only support 32 bit addresses and other nodes can't get
a globally unique 32 bit address, you are forced into a world
of hurt that requires some combination of NAT, tunnels and
dual-stack. That is completely independent of the design of
IPng, and we knew it 1994.

So while your criticism is valid that we collectively came up
with too many such combinations, that collective mistake was
(IMHO) not a result of the design of IPv6 as such. It was more
caused by the design of human beings.

> It doesn't
> application-layer APIs).  

It's true, but to avoid that, I think we'd have to abolish
cellular telecommunications, Wi-Fi, and competition between
providers.

> One of the original promises about

Right, but again - only part of that is due to the change of
address size and socket API details. Most of it is due to
multiple connectivity. That was going to happen anyway.

> else" was the only viable solution for IPng, 

Don't forget, BTW, that even "just" changing address size
from 32 to 64 would have blown up almost every app written to
BSD sockets (since Real Programmers Don't Use Structures and
almost everybody used to stick addresses into uint_32).
There never was a free lunch on the table.

   Brian

> but I don't think

---

From: Masataka Ohta <[email-masked]>
Date: Sat, 01 Jun 2013 13:44:16 +0900

> 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.

> to most applications.  Ha!

There is no need for IPv6 specific changes.

						Masataka Ohta

---

From: Doug Barton <[email-masked]>
Date: Fri, 31 May 2013 23:05:36 -0700

On 05/31/2013 09:35 PM, Brian E Carpenter wrote:
> stateless auto-configuration

Brian,

Not picking on you here, in fact I'm agreeing with you regarding the 
early days. In '94 SLAAC/RA was a good idea, and remains a good idea for 
"dumb" devices that only need to know their network and gateway to be 
happy.

What continues to astonish however is that 15 years after DHCP took off 
for IPv4 the IPv6 luminati are still singing the 2-verse song, "You must 
use SLAAC," and "You may not have full-featured DHCPv6."

Whatever good intentions were in place 20 years ago (and I do not doubt 
that they were good intentions), the situation right now is beyond 
absurd, and serves as an excellent example of why a non-trivial number 
of operators don't take the IETF seriously.

Doug