Subject: [rrg] Multiple critiques, choice of single proposal, consensus on constraints due to voluntary adoption?

From: Robin Whittle <[email-masked]>
Date: Sat, 30 Jan 2010 15:17:50 +1100

Short version:     What objections are there to having two or more
                   well written, generally non-overlapping, ~500
                   word critiques for a proposal if the authors can't
                   figure out a way to express all their concerns
                   in a single ~500 word piece?

                   Also, would there be any problem in attributing
                   authorship of the one or more critiques?

                   I understand the plan for Summary, Critique,
                   "Rebuttal" and Reflection.  What is the plan for
                   debate and hopefully achieving rough consensus (or
                   better than rough) support for a choice of a
                   single proposal (or maybe two or more?) to
                   recommend to the IETF?

                   The options for altering the architecture to
                   achieve scalable routing and addressing are
                   tightly bounded by the installed base and by
                   the need for widespread voluntary adoption.

                   My page on some of these constraints:

http://www.firstpr.com.au/ip/ivip/RRG-2009/constraints/

                   has been fine-tuned as a result of
                   considerable RRG discussion.  As far as I
                   know no-one objects to this attempt to
                   express the real constraints we are
                   operating within.  Quite a few people
                   expressed their support for this attempt -
                   though of course we all wish there were no
                   such constraints.

                   I suggest that we work on a version of this
                   to be included in the RRG Report, which
                   the co-chairs will hopefully be able able
                   to find rough consensus support for.

                   Could the Report include a section near
                   the front classifying the proposals into
                   various groups?

Hi Lixia and Tony,

I support more than one critique being included in the RRG Report.

After all the words which have flowed on this list - many of them of
no lasting consequence regarding scalable routing - I can't see a
problem with the RRG Report containing more than 500 words of
critique, or more than one critique, for each proposal.

Some proposals are still without a critique - though I hope to write
one for each of these as soon as I can.

Some proposals are so extensive and potentially important - in that
they have a chance of being chosen as the future Internet
architecture - that they really should have more than 500 words
devoted to assessing them.  This can easily be shown by the fact that
two or more people are motivated to write their own critiques.

RFCs are composed entirely of recycled electrons.  They will take up
space in IETF servers and search-engine databases for decades or
centuries to come.  But so does every message on this list.

As long as each critique is reasonably well written and contains
significant material which is not found in the other critiques - and
and as long as those who wrote them would prefer their own critiques
and those of others to appear alongside each other to the prospects
of just one being chosen, or some attempt to jam all the ideas into a
single body of 500 words - then what objections are there to the
Report including multiple critiques?

You decided on the 1000, 500, 500, 500 word format for Summary,
Critique, "Rebuttal", and Reflection.  No-one but Tony seems to have
insisted on the 500 word limit, or the need for just one critique -
so I am not suggesting a change to against anything which has been
decided by consensus.

My LISP critique is in the current draft of the Report:

  http://tools.ietf.org/html/draft-irtf-rrg-recommendation-04

and Noel Chiappa's:

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

isn't, simply because I wrote mine before Noel wrote his.

I don't want Noel's critique to displace mine, nor mine to displace
his.  I think they are both perfectly good critiques and there is
only a small amount of overlap.

I want Noel's critique included in the Report.  Likewise any other
similarly thoughtful critique of LISP or any other proposal.

I also suggest that these critiques be attributed to the people who
created them.

The RRG Report needs to be adopted by consensus, and I won't fully
support a final version which I think is missing a significant
critique such as Noel's or my (not yet finalised) critique of Name
Based Sockets.

Similarly, Javier's critique of Name Based Sockets is in the current
draft and mine is not, simply because Javier wrote his first.

I do not want my critique to displace Javier's.  As far as I know, he
doesn't want to exclude mine from the Report either.  I don't want to
have to try to jam my concerns into a single piece of text which
Javier would also be happy with.  There is a diversity of opinion on
what needs to be critiqued in each proposal - and there's no point in
trying to force consensus or give the appearance of consensus when
none exists.

I might support collaboration on a single critique if there was no
500 word limit.  I think it would be better to have a 500 word limit
- if you must have one - and to allow multiple critiques.

If you persist with the current plan, then the RRG Report will
reflect arbitrary choices between multiple perfectly good critiques.
 Furthermore, the Report would not attribute the single critique to
any author - which would imply that the text resulted from
collaboration and reflected rough consensus.

You and Tony have already changed your plan by accepting a proposal
very late - RANGER.  No-one seems to object to this.  You have also
accepted five proposals which are not actually proper scalable
routing proposals:

  Evolution - Aggregation with Increasing Scopes

     This does not claim to solve the scaling problem - it is
     a number of suggestions for reconfiguring routers to achieve
     benefits which are very slight compared to the scaling
     benefits we need, but which may prove valuable while not
     getting in the way of a proper solution.

  Enhanced Efficiency of Mapping Distribution Protocols ...

    In the submission (msg05540) K. Sriram noted that this was
    intended for archival purposes:

         "I do not intend it to be a contribution for the mainstream
          set of proposals for a solution for scalability.  . . .
          My main intent in submitting this proposal/document is for
          archival value."

  2-phased mapping
  Layered Mapping System (LMS)
  Compact routing in locator identifier mapping system

    As with "Enhanced Efficiency ..." these three are for mapping
    systems only, not full proposals.

I am not opposed to the inclusion of these five which were submitted
despite Tony noting twice (msg05513, msg05496) that a mapping system
alone is not a complete solution.

I don't understand how you could be so relaxed about space concerns
when including these five, and then be so concerned about space as to
disallow the inclusion of multiple critiques for those complete
proposals which people are most concerned about.

Agreement and support is a rare commodity on this and many other
discussion lists.  I think my attempt to list a particular subset of
the constraints we face:

  http://www.firstpr.com.au/ip/ivip/RRG-2009/constraints/

achieved good support from a number of people.  No-one argued that
the list was not reflecting reality, though constraints 8, 9 and 10
are "sliding scale" constraints, where the partial failure to meet
them only reduces the chance of success, rather than eliminates it.

I suggest that the RRG Report contain a version of these for which
the co-chairs can find consensus support for.   I can work on
rewriting it into a suitable form for a section in the Report - but
would be happier if someone else did it, or at least helped me with
it.  It could be an appendix, but I think these constraints are
important enough to be near the start of the Report.

Also, I think the Report would be enhanced by some guidance near the
start, which again would need to be supported by RRG consensus, on
the nature of the proposals.  I haven't yet read all the proposals,
but my thoughts on this are:

   Core-Edge Separation (CES) architectures

      v4  v6   Ivip
      v4  v6   LISP
          v6   RANGER
      v4  v6   TIDR

   Core-Edge Elimination (CEE) architectures

          v6   GLI-Split
      v4       hIPv4
          v6   ILNP
          v6   Name Based Sockets
      v4  v6   Name Overlay Service
          v6   RANGI

   Proposals concerning only mapping distribution systems

      2-phased mapping
      Compact routing in locator identifier mapping system
      Enhanced Efficiency of Mapping Distribution Protocols ...

   Improving router utilization as a prelude to adopting a solution

      Evolution - Aggregation with Increasing Scopes

Can you articulate your plans for how the RRG will discuss and
hopefully achieve consensus support for a choice of which proposal to
recommend to the IETF?   Tony has written several times that the aim
if for a single recommendation.  There's only four or so weeks left.

  - Robin

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 30 Jan 2010 11:10:43 -0500

The main thrust of this email seems to assume a fact not in evidence.

The plan described by the chairs does not envision a document providing 
complete coverage of all ideas presented to the RRG< nor does it 
describe providing a complete and thorough analysis of each idea.
rather, it provides a survey of the ideas, with some commentary.

Personally, I can not foresee any process which would come to an actual 
agreement on a recommendation from the RRG, and therefore conclude that 
the survey is probably the most effective outcome we can achieve as a 
community.

I will note in passing that it is quite rare in IETF or IRTF documents 
to attribute authorship of particular portions.  (There are exceptions 
when the WG wishes to acknowledge a particular contribution of 
particular value that comes from a single person, but even that is done 
sparsely.)

Yours,
Joel

PS: I would suggest looking at the introduction (the abstract needs to 
be updated) of the most recent document.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 30 Jan 2010 11:14:10 -0500

Personally, I would object to including that effort in the report.
While I laud your efforts to try to pull things together.  I personally 
find many of the distinctions ineffective or misleading.  The text 
itself is not wrong (generally), but I find it sufficiently unhelpful 
that I have not tried to analyze it for accuracy.

Also, as those constraints were not adopted by the working group, and 
were not adopted by the proposers of the various approaches, including 
it in a survey of our work would not help the reader in any significant 
fashion.

Yours,
Joel

---

From: John E Drake <[email-masked]>
Date: Sat, 30 Jan 2010 08:34:41 -0800

I agree with Joel.  Enough is enough.

John

Sent from my iPhone

On Jan 30, 2010, at 11:14 AM, "Joel M. Halpern" <[email-masked]>  
wrote:

> _______________________________________________
> rrg mailing list
> [email-masked]
> http://www.irtf.org/mailman/listinfo/rrg

---

From: Dino Farinacci <[email-masked]>
Date: Sat, 30 Jan 2010 09:12:52 -0800

> I agree with Joel.  Enough is enough.

I third the motion.

Dino

---

From: Robin Whittle <[email-masked]>
Date: Sun, 31 Jan 2010 04:33:53 +1100

I am replying to Joel about whether the report will contain a
recommendation and about the choice and nature of critiques.

Maybe I misunderstood what we are aiming for in the next month or so.

Hi Joel,

You wrote, in a different order:

> PS: I would suggest looking at the introduction (the abstract needs
> to be updated) of the most recent document.

OK - I hadn't read this:

   It is commonly recognized that the Internet routing and
   addressing architecture is facing challenges in scalability,
   multi-homing, and inter-domain traffic engineering.  This
   document reports the Routing Research Group's preliminary
   findings from its efforts towards developing a recommendation
   for a scalable routing architecture.

   This document is a work in progress.

Perhaps I missed something.  I was under the impression that the RRG
was to provide a recommendation to the IETF, and that this March was
the deadline.  The original deadline, to the best of my knowledge,
was March 2009 but was extended - I assumed for a year.

Lixia and Tony, can you clarify this?

If the RRG is not going to recommend anything in this next report,
then that's fine.  Then I understand that the report will be a survey
of the proposals - and I think the format of Summary, Critique,
"Rebuttal" (perhaps too strong a term?) and Reflection is a good one.

But here is an exchange between Tony and myself on 2009-12-25 which
makes me think that this report will contain the recommendation.
What is the timeframe for this?  I had assumed it would be in the
version we create in early March:

  RW>> But the resulting document doesn't seem to resemble a
    >> "recommendation" to the IETF.

  TL>  It's not the final step.  This creates the full background.
    >  At the end we will have documented each proposal and made
    >  arguments pro and con for each of them.

    >> Is the RRG's final recommendation going to be in a separate
    >> ID from the one with the summaries, analyses, rebuttals and
    >> counterpoints?
    >
    >  No, it should be the same document.

    >> Could the recommendation be split into sections according
    >> to time-frame and/or for IPv4 and IPv6?
    >
    >  That depends entirely on what the recommendation ends up
    >   being.

    >> There are divergent viewpoints about how important it is to
    >> solve the IPv4 scaling problem and how urgently we need to
    >> work on the IPv6 scaling problem.  Maybe the RRG will reach
    >> consensus on this and so be able to recommend a single
    >> approach.
    >>
    >> If there is no broad consensus or this on anything else,
    >> will the final recommendation try to summarise the two or
    >> more major groups of viewpoints?
    >
    >  We hope for broad consensus.

> The plan described by the chairs does not envision a document
> providing complete coverage of all ideas presented to the RRG nor
> does it describe providing a complete and thorough analysis of each
> idea.

Sure, but if two or more people contribute critiques, which are
either incompatible to a significant extent or which cover different
concerns, then rather than choose a single one arbitrarily, why not
include them both?

At 500 words each, they are not particularly long.

> Personally, I can not foresee any process which would come to an
> actual agreement on a recommendation from the RRG, and therefore
> conclude that the survey is probably the most effective outcome we
> can achieve as a community.

So you suggest we should present the IETF with a bunch of proposals
on a platter, with critiques which may be an arbitrarily chosen
subset of those generated, and no recommendation?

Tony wrote clearly of a recommendation just over a month ago.

> I will note in passing that it is quite rare in IETF or IRTF
> documents to attribute authorship of particular portions.  (There
> are exceptions when the WG wishes to acknowledge a particular
> contribution of particular value that comes from a single person,
> but even that is done sparsely.)

OK - this is fine if there everyone or most people are happy with the
text.

If my LISP critique is the one that stays in the report, than that
will make me happy, but not as happy as if Noel's critique was
included too.   I think Noel wants both included.

Likewise, I think Javier's critique of Name Based Sockets is not at
all adequate if it is the only critique to be included.  I am keen
for mine (still to be finalised) to be included too.

I would be perfectly happy for multiple critiques of Ivip to be included.

 - Robin

---

From: Robin Whittle <[email-masked]>
Date: Sun, 31 Jan 2010 04:56:16 +1100

Replying to Joel, John Drake and Dino regarding including a section
on the constraints imposed by the need for widespread voluntary adoption:

Hi Joel,

You wrote:

> While I laud your efforts to try to pull things together.  I
> personally find many of the distinctions ineffective or misleading.
> The text itself is not wrong (generally),

"Ineffective or misleading" means "wrong".

> but I find it sufficiently unhelpful that I have not tried to
> analyze it for accuracy.

OK - so you think it is a worthwhile thing to write about, but you
don't like the way I have done it.  You say you find many shortcomings
with it, but you haven't given any specifics.

You don't think it should be in the report - but I wasn't suggesting
using exactly this text.  I suggested improving it.

I am happy to work with you and other people rewriting it.  I would
be happier if you or someone else rewrote it or created a fresh
version without my help.

This whole discussion is overshadowed by the constraints on what we
can do, and probably the most important set of constraints arise from
the need for widespread voluntary adoption.  I think these should be
documented.

> Also, as those constraints were not adopted by the working
> group, and were not adopted by the proposers of the various
> approaches, including it in a survey of our work would not help
> the reader in any significant fashion.

Sure - I wasn't suggesting they had been adopted.

I suggested improving them to the point where hopefully there would
be broad consensus that the text was worth including.

You haven't given me any feedback on what needs improving.

> I agree with Joel.  Enough is enough.

Of what?

>> I agree with Joel.  Enough is enough.

Dino, do you think the constraints we face - such as those due to the
need for widespread voluntary adoption - are important?

If so, then lets document them.

  - Robin

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 31 Jan 2010 09:00:38 +1300

It seems worth pointing out that if Microsoft, Apple and the Linux
maintainers include something in their network stacks, widespread
involuntary adoption is only a matter of time.

At least in the case of IPv6, this has proved much easier than
getting something adopted by CPE vendors or ISPs.

   Brian

---

From: Tony Li <[email-masked]>
Date: Sat, 30 Jan 2010 13:58:01 -0800

Hi,

> Lixia and Tony, can you clarify this?

<chair>
Yes, our deadline is extended until March of this year.  At that time, 
we still aim to present a recommendation.  Specifically, we hope to 
present the recommendation when we meet in Anaheim.  We acknowledge that 
more time (on the order of single-digit weeks) may be necessary to 
finalize the document.

Please note that we are part of the IRTF, not the IETF and are not bound 
  by the constraints of 'rough consensus'.  While achieving 'rough 
consensus' would be optimal, given the time left that seems dubious. 
Our goal is still to make a recommendation on schedule.

Please note that there is a placeholder section at the end of the 
current draft for exactly this.
</chair>

Regards,
Tony

---

From: Lixia Zhang <[email-masked]>
Date: Sat, 30 Jan 2010 22:18:36 -0800

Hi Robin,

I see that a number of people have responded to this msg. I'll just  
chip in a few more sentences here and there.

>                   in a single ~500 word piece?

As I mentioned in the prev msg: we would like to summarize all the  
issues with each proposal into one critique. I understand that  
agreement some times is difficult (hence rough consensus needed).

> ......

Looks like there is no consensus for this proposal.
ANyone can always submit their work as individual draft, perhaps you  
can even working with the few people that share your views.

>                   the front classifying the proposals into

will try to look into this.

> ......
> RFCs are composed entirely of recycled electrons.

this is very true. However I think there is an important bottleneck:  
people's time and effort, which are very limited.

> ......

it is purely my fault -- I agreed to look over both and find a  
solution here last weekend; will get it done this weekend.

> .....
> The RRG Report needs to be adopted by consensus,

rough consensus.

> and I won't fully

Robin, I would like to clarify the following:

- the reason one writes critiques is not to associate one's name to  
it, but to explain the issues. Lets stop talking about "my critique"  
vs "your critique", and start talking about the actual issues  
themselves.

- if we focus on issues: we can either resolve the diversity of  
opinions, or otherwise incorporate them if that deems beneficial to  
the community.

> ......
> very late - RANGER.  No-one seems to object to this.

there was a confusion somewhere that led to the RANGER delay. and  
since we want to document all existing proposals, in case of doubt, it  
is better to fall on the inclusive side.

> You have also

(my own opinion) we want critiques to identify issues with a proposal,  
I see it is most beneficial to the community to have all the issues  
(including different views) about a proposal in one place.

Lixia

---

From: Robin Whittle <[email-masked]>
Date: Sun, 31 Jan 2010 18:07:30 +1100

Hi Lixia,

Thanks for your reply.  On adding a section regarding the constraints

> Looks like there is no consensus for this proposal.

OK - it was just a suggestion.

> ANyone can always submit their work as individual draft, perhaps
> you can even working with the few people that share your views.

I would like to do this.  If anyone wants to help, please contact me
offlist.

> issues with each proposal into one critique. I understand that agreement
> some times is difficult (hence rough consensus needed).

It is unrealistic to expect individuals to reach rough consensus on
anything.  If we can, then that's great.  If we can't, this needs to
be respected and documented.

> will try to look into this.

OK.  I think some kind of guide is really important. The
classification I gave is my opinion, and I haven't yet read all the
proposals fully.  Perhaps my text could be the starting point for you
and Tony developing a classification for which there would be rough
consensus.

Is there any reason for the current order of proposals?  It seems not
to follow alphabetical or any other order.

> people's time and effort, which are very limited.

Yes, but 500 words is an impossible constraint if you want to cover
the divergent and sometimes contradictory view of two or more people.

I think it would be a bad use of other people's and my time to try to
nut out a 500 word critique of Name Based Sockets we could all be
happy with.  If you can work with Javier to include your concerns in
his text, then that's great.

If you can't handle multiple critiques in the Report, I will make an
ID to include all the critiques for any proposal for which more than
one critique has been offered.  There won't be a 500 word limit, and
each one will have the name or the one or more authors.

We have done a lot of work on a very important and difficult subject.
  The critiques are perhaps the most concentrated and vital resource
for anyone trying to understand scalable routing.  The critiques are
hard to find in the archives, and I think that for long-term access,
having an ID or ideally an informative RFC is a better way to make
the full range of critiques accessible.

> it is purely my fault -- I agreed to look over both and find a solution
> here last weekend; will get it done this weekend.

Noel wrote:

  I don't really care whether both, or just one, are included.

so I understand acceptable to him and me for my critique to remain in
the Report.  However, I am on the record as stating that I would
prefer Noel's and anyone else's to be included too.

Noel's critique, mine and anyone else's will be in my forthcoming ID.

>> The RRG Report needs to be adopted by consensus,

OK, that is what I meant - though Tony wrote:

   Please note that we are part of the IRTF, not the IETF and are not
   bound  by the constraints of 'rough consensus'.  While achieving
   'rough consensus' would be optimal, given the time left that seems
   dubious. Our goal is still to make a recommendation on schedule.

> - the reason one writes critiques is not to associate one's name to it,
> but to explain the issues. Lets stop talking about "my critique" vs
> "your critique", and start talking about the actual issues themselves.

I am not trying to get my name associated with a critique for my own
sake - but people who read a critique in the RRG Report need to know
where it came from.  I guess they can look at the list archives if
they want, but that would be a time-consuming and error-prone task.

My critiques focuses on the issues.

There isn't a single 500 word document which can convey the issues I
am discussing with those that Noel is discussing.  Both of us already
chopped down longer texts to get to 500 words.  Likewise with
Javier's any my concerns about Name Based Sockets.

If you had no word-count limit on the critiques for the Report, then
it would be possible to combine discussion of the issues from the
various perspectives as required to represent the concerns of
multiple people.

> opinions, or otherwise incorporate them if that deems beneficial to the
> community.

I think it is unrealistic and unreasonable to expect that separate
individuals can or should agree, or that they could be happy with
trying to further truncate the expression of their ideas to force-fit
it into an arbitrary word limit such as 500 words.

> there was a confusion somewhere that led to the RANGER delay. and since
> we want to document all existing proposals, in case of doubt, it is
> better to fall on the inclusive side.

OK - I think RANGER should definitely be included.

> (my own opinion) we want critiques to identify issues with a proposal, I
> see it is most beneficial to the community to have all the issues

Sure - but for some proposals, it is impossible to adequately express
the concerns of multiple people in 500 words.

  - Robin