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
_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg
