Hi Tony,
I now understand that all 14 proposals are included, but that you
expect the critique ("analysis", I think) of the 4 proposals I
mentioned first would be "somewhat pointed" - presumably by
mentioning that they are not actually solutions to the routing
scaling problem.
I think the same is true of the last proposal I mentioned, which I
think is a collection of previously documented techniques which may,
at best, marginaly improve the ability of a network to cope with
DFZ routing table growth without buying too many new routers. This
falls far short of a a proper solution - which will involve the
ability to scalably provide millions or billions of end-user networks
with portability, multihoming and TE.
You wrote:
>> I understand the proponents are to find and choose one or more
>> people (ideally several: "collaboration of a number of people" to
>> write the "analysis" - but that the proponents can't write or
>> contribute to that analysis themselves. So these analyses will
>> presumably be reasonably positive - or as positive as the
>> proponents can persuade anyone to write!
>
> No, it is NOT up to the proponents to coordinate the analysis. It
> is open to the group to do so. I would expect them to be direct,
> succinct and quite possibly critical.
Sorry - my previous message was based on my misunderstanding that the
proponents of each proposal would solicit an analysis for their
proposal. I also misunderstood the "rebuttal" to be of the proposal,
rather than of the analysis.
>> Then there will be a 500 word "rebuttal" of the proposal. This will
>> be solicited by Lixia and yourself. Is this to be written by one
>> person or more? Will you ask particular people to write this - or
>> will you accept contributions from anyone? How would you choose the
>> people or between contributed rebuttals? Is anyone to contribute a
>> rebuttal to the RRG list, or should we do it in private to the co-chairs?
>
> I would expect this to come from the proponents, but that's not a strict
> requirement. If there are multiple submissions, we reserve the right to
> choose one wholly arbitrarily. Thus, it is in everyone's interest to
> collaborate if at all possible.
OK. It's not clear how the group is supposed to coordinate these
analyses. Who wants to step forward and be one one of the
official party-poopers of a proposal, asking for others to join them?
(I volunteer to collaborate on critical analyses of LISP and TIDR -
the only two proposals which I think have a hope of being adopted.)
What if no-one cares enough about a proposal to read it
comprehensively and write an analysis?
>> Is "rebuttal" too strong a term to use? I guess a critique could
>> either be in terms that the proposal cannot possibly work - which is
>> a rebuttal - or that it could work, but not as well as some other
>> proposal. That could be tricky to do respectfully (with sufficient
>> details, arguments and qualifications) in 500 words, since it also
>> involves evaluating at least one other proposal which would be argued
>> to work better.
>
> It's what we've chosen. Comparing against another proposal is not the
> intent. These should be clear debates about the pros and cons of
> individual proposals in isolation.
Since our goal is to choose the best proposal, I don't see how we can
avoid thinking and presumably writing about other proposals.
There are at least two types of "cons": Firstly, those which make
the proposal untenable or undesirable irrespective of alternatives.
Secondly those where the proposal is perhaps feasible, but another
proposal does something significantly better than this proposal.
With "pros", some advantages of a proposal are unique to the proposal
- which should be mentioned as such. Other "pros" are significant in
terms of degree - that no other proposal does something so well.
Both types of statement involve negative value judgements about
either all other proposals, or about particular other proposals.
These value judgments need to be made - and they need to be supported
by arguments, which your sentence above does not seem to allow for.
These pros and cons are absolutely central to the final choice of
proposal.
>> Then you will solicit "another counterpoint". "Solicit" indicates to
>> me that you won't simply ask the proponents for a "counterpoint" but
>> that you will ask someone to write something - or accept potentially
>> multiple counterpoints and either choose one, or encourage the
>> authors to work together to produce a single one.
>
> The intent is that this would come from the same folks that wrote the
> analysis.
OK.
>> Will people contribute counterpoints freely on the list, or directly
>> to you? I guess the counterpoint is to the "rebuttal" - so it can
>> only be written after the rebuttals are finalised.
> Either mechanism is fine. Yes, these are necessarily sequential.
OK - I understand this process for the counterpoints. I am not clear
how you want people to self-organise the "analysis" stage. Do you
want draft or final "analyses" to be sent to the list? I think that
would be a good way to further discussion and prompt other people to
become involved in contributing to a better analysis if they feel
those posted to the list could be improved upon.
For each proposal I understand there will be:
Summary. Written by proponents.
Critical analysis. Written by self-chosen group members, other
than the proponents, who ideally work together
on a single piece - otherwise the co-chairs
will need to choose between several.
Should be critical without any attempt to
compare it with other proposals.
Deadline 12 January (msg 5558).
Rebuttal of the above. Written by proponents.
We can start on this after 12 January.
Counterpoint. After the rebuttals have been finalised.
Could be written by the authors of the
critical analysis - or maybe someone else.
Counterpoints to be offered on-list or
directly to the co-chairs. Co-chairs will
chose one if multiple are offered.
>> While it looks tricky, I can see some value in this set of pieces of
>> writing.
>>
>> But the resulting document doesn't seem to resemble a
>> "recommendation" to the IETF.
>
> 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.
Yes, but these will be very constrained in terms of word-count and
you don't want the analysis (critique) to mention other proposals.
Presumably the on-list discussion will make up for these restrictions.
>> 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.
OK - so I think I understand the process for summary, analysis,
rebuttal and counterpoint.
There are no deadlines yet for the final two states of that, and no
guidance yet from you or Lixia on how we will develop a
recommendation before early March.
I understand from:
http://www.ietf.org/mail-archive/web/rrg/current/msg05558.html
that an ID needs to be submitted by 2010-03-01, but that it can be
updated until 2010-03-08.
- Robin
_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg
