Subject: Re: [Geopriv] Irregularity at the GEOPRIV Meeting at IETF 68

From: Bernard Aboba <[email-masked]>
Date: Thu, 19 Apr 2007 20:49:16 -0700 (PDT)

In reading the messages posted to the list relating to the GEOPRIV WG 
meeting at IETF 68, it strikes me that we have a situation in which
a deadlock was allowed to persist for much too long. 

Whether "standard" or "alternative" mechanisms of consensus determination
can resolve this situation seems almost besides the point -- a huge amount
of energy and time has already been wasted. 

Looking backwards, many of the IETF's most heated battles did in fact
resolve themselves in clear outcomes, but only years afterwards once
it become clear that one or more of the proposed approaches had little
or no support in the marketplace.  For example, recall the 
LDP vs. RSVP-TE debate. 

Given this, I would suggest that debating whether the IESG did the
right or wrong thing at IETF 68 is somewhat besides the point. 

Instead, I would like to ask whether we are furthering
the interest of the Internet community by allowing deadlocks to
persist for long periods, rather than quickly recognizing them and
defusing the situation by publishing the competing
approaches, allowing the market to decide which one is "best".

Cullen Jennings said:

"Area Directors who manipulate schedules and agendas in order to 
predetermine the outcome of consensus calls should, in our opinion, be 
summarily recalled, and if the GEOPRIV working group chairs believe this 
transpired in IETF 68, we urge them to pursue such a recourse."

Ted Hardie said:

I urge them not to.  Let's try to work this out without creaking into 
effect a never-used aspect of our process.  Pushing it to that extreme 
looks contrary to our usual effort to achieve consensus; let's continue 
talking to each other instead.  If either the Area Directors or chairs is 
no longer willing to talk about the problems and resolve them, I think 
we're in a sorry state.  If we've gotten there, let's try and back away.

John Schnizlein said:

There is reason to suspect that the maneuvers in Prague are part of
an agenda to move control over a host's location from the host to the
network operator in order to create a business of providing it.
There is a pattern with implications on the outcome of the WG, not
just procedural lapse.

Martin Dawson said:

The conspiracy theory is quite simply wrong. 

James Polk said:

energy and misrepresentation doesn't make things right either....

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: John C Klensin <[email-masked]>
Date: Fri, 20 Apr 2007 10:01:51 -0400

--On Thursday, 19 April, 2007 20:49 -0700 Bernard Aboba
<[email-masked]> wrote:

> In reading the messages posted to the list relating to the
> GEOPRIV WG  meeting at IETF 68, it strikes me that we have a
> situation in which a deadlock was allowed to persist for much
> too long. 
> 
> Whether "standard" or "alternative" mechanisms of consensus
> determination can resolve this situation seems almost besides
> the point -- a huge amount of energy and time has already been
> wasted. 
> 
> Looking backwards, many of the IETF's most heated battles did
> in fact resolve themselves in clear outcomes, but only years
> afterwards once it become clear that one or more of the
> proposed approaches had little or no support in the
> marketplace.  For example, recall the  LDP vs. RSVP-TE debate. 
> 
> Given this, I would suggest that debating whether the IESG did
> the right or wrong thing at IETF 68 is somewhat besides the
> point. 
> 
> persist for long periods, rather than quickly recognizing them
> and defusing the situation by publishing the competing

Bernard,

This comment worries me a bit, but it may be that I don't
understand  what you are suggesting.  Ignoring GEOPRIV but
speaking very generally, I think we actually have three
different types of deadlock situations and that they call for
different approaches.

(1) Deadlock is apparent but not real: the WG actually has rough
consensus, but the minority positions of a few people are being
expressed loudly and aggressively enough to make the consensus
less obvious and block progress.  This calls, IMO, for some
relatively aggressive behavior on the part of WG leadership and,
if necessary, ADs.  Letting the dissenters "win" by publishing
their approach as co-equal with the agreed-upon better technical
solution is bad for the Internet and bad for the IETF.

(2) Deadlock is between solutions to different problems.  What
is needed is to move beyond arguments about which problem is the
"correct" one to a clear definition of each of the problems and
ways to determine which one is relevant to a particular case,
followed by protocol options or different protocols to select
the relevant problem and the approach that follows.

(3) Deadlock is due to having competing approaches to the same
problem with no clear technical justification for choosing one
rather than another.  Publishing all approaches and letting the
marketplace decide almost guarantees non-interoperable solutions
and is, IMO, a disservice to everyone involved.  The WG needs to
make a choice as to which one to recommend, even if it has to
admit (and document) the fact that the solutions are equivalent
and even if the choice is made at random, by delegation to a
subcommittee or the AD, etc.   If it cannot make or agree to a
choice, then, IMO, the WG should be shut down and _at most_
documents be published as informational descriptions of the
different approaches.

>From my point of view, any time the IETF makes a decision that
lowers the odds of interoperability, we fail.   If there are no
alternatives to that sort of failure, we should be explicit
about having done so and, ideally, explain and document the
reasons why the failure occurred.  Certainly, letting deadlocks
drag out for a long time is another kind of failure and we
should try to make them go away as described above.  But
replacing deadlock-failure with interoperability-failure is not
necessarily a good choice.

    john

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 20 Apr 2007 12:45:57 -0700 (PDT)

> solution is bad for the Internet and bad for the IETF.
  
This approach may or may not work, depending on who the dissenters are.
Part of the problem with the loss of the multi-stage standards process
over the years is that the importance of "running code" has been
diminished within the IETF standard process, while in the market
place the importance of implementation remains as strong as ever. 
   
As a result, if the dissenters represent all the likely implementers, 
refusing to publish their protocol will only result in approval of a 
"bogo-standard" with little industry support, and interoperability issues 
resulting from the lack of documentation for the approach that is actually
widely implemented.  For example, would it have served the interest of
the Internet community to have suppressed the publication of the
Ethernet specification in deference to IEEE 802 SNAP encapsulation? 
While the Ethernet proponents were in the minority within IEEE 802
at the time, their approach quickly became a defacto standard. 

As a result, I do not believe that a determination of "rough
consensus" is sufficient; "running code" also needs to be taken
into account. 

> the relevant problem and the approach that follows.

This particular case seems most relevant to the GEOPRIV WG case, where
the argument seems to be about whether location is best handled on the
host or in the network, and which protocol proposals meet "the
requirements".  Rather than attempting to find a single "best"
solution to a single set of requirements, it would probably have been
better to recognize that in fact the two approaches may not be
solving the same problem. 

> documents be published as informational descriptions of the

I would disagree that "flipping a coin" in this case is likely to 
provide better interoperability either in the short or long term, 
since this takes into account neither consensus nor running code. 

One of the things we learn from the history of networking is that
while competing approaches may persist in the short term, in the
long term a single winner typically emerges.  By suppressing
all approaches in the interest of "interoperability" we merely
delay the market-sorting process, prolonging the period of confusion. 

Even worse, the IETF track record does not suggest a strong ability
to pick the eventual market leader, providing a significant probability
that the IETF process will actually retard the development of
market consensus.  For example, an examination of initial track 
designations (Informational, Experimental, Standard) does not 
demonstrate a strong correlation with eventual success.  

Part of the problem here is that the intricacies of the IETF process,
while well suited to the evolution of existing protocols, does not
do a good job of developing innovative solutions to new problems. 
In such situations, the protocols most likely to succeed are those
that "only just work": proposals that are simple to implement and
include only the bare minimum functionality necessary to solve
the problem.  It is exactly these kind of proposals that are most likely
to fare poorly in the IETF review process.   For examples, see
Mark Handley's paper "Why the Internet Only Just Works":
http://www.cs.ucl.ac.uk/staff/M.Handley/papers/only-just-works.pdf

If we look at the protocols that are at the core
of much of what we do on the Internet today, many of them faced an
uphill battle in the IETF, and were only accepted once their widespread
implementation became too obvious to ignore (e.g. BGP). 

As a result, one may conclude the IETF's strength lies not in the
process for publication of WG work items, but rather in its ability
to embrace approaches developed outside the IETF, or which had
previously been sidelined within the IETF.   This is in part what
makes the Independent Submission process so important.

---

From: "Tschofenig, Hannes" <[email-masked]>
Date: Sun, 22 Apr 2007 12:04:54 +0200

Hi Bernard, 

I agree with your statement that we should let the market decide when it
comes to this particular case where we have many different solutions
(developed by different SDOs) already. 

Let me add one more message that got posted to the GEOPRIV mailing list
in this context: 

Lyn Moore said:
"
Hello Everyone
 
I am enjoying the blame game that some of you are indulging yourself in.
 
Two camps (and I will use company names because it has become obvious
that this is what is happening) - 
1. Cisco - I want to have location in the home router - presumably
because I know how this would work and then I can sell more routers.
2. Andrew Corp - I want to have location in the network - presumably
because I know how this would work and then I can sell more boxes.
 
Oh dear folks.  After all this time it seems to have come down to this.
I am unfortunately I work for a telco waiting for a deployable answer.
I am coming to the conclusion that the IETF won't be supplying it. 
"

Ciao
Hannes

> determination