Subject: [rrg] DIY Recommendations

From: Robin Whittle <[email-masked]>
Date: Mon, 19 Apr 2010 12:32:31 +1000

Short version:  RRG participants should contribute to the debate by
                having a go at writing their own preferred goals and
                Recommendation and/or by critiquing other people's
                attempts to do so.

Med Boucadair (msg06442) and Wes George (msg06443) both expressed a
desire for the co-chairs to substantiate their proposed
Recommendation.  I imagine most RRG participants and everyone who
reads the final Recommendation would have the same expectation.

Yet, after 6457 messages, I am the only RRG participant to attempt to
write a Recommendation with such substantiation - with a defined set
of goals and analysis of all the proposals.

If Lixia and Tony produce no such clarification of their goals and/or
no substantiation of their choices, their Recommendation will
no-doubt be criticised and/or ignored.

Whatever substantiation they do provide will no-doubt fail to satisfy
many RRG participants.

I think RRG participants could aid the debate, and help the
co-chairs, by writing their own DIY Recommendations to the list.
Even if each attempt is incomplete - such as only referring to a
subset of the proposals - as long as it contains arguments for or
against at least some proposals, together with an explicit statement
of the goals with supporting arguments for these, then this would
further the debate and give the co-chairs something to consider as
they write their text.

There are major questions regarding goals:

   IPv4 vs. IPv6.  One or the other first, or not bother with IPv4?

   Coping with the continued (highly constrained) rate of growth in
   multihomed end-user networks vs. allowing a much greater rate of
   growth (to better match the needs of end-user networks) in a
   scalable manner.

   Having the architectural enhancement directly facilitate mobility
   or not.

   Core-Edge Elimination (Locator / Identity) vs, Core-Edge
   Elimination vs. other kinds of architecture or work-arounds.

My 8 March attempt to do this is here:

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

but please see recent messages for the latest IRON-RANGER developments.

I guess most RRG participants have some opinion on what should be
recommended.  Since everyone expects the co-chairs to Get It Right, I
think more people should attempt what they expect the co-chairs to
do: define goals, evaluate proposals, and make choices.

Even if an RRG participant hasn't got a clear idea of what to
recommend, or hasn't read all the proposals, I think they could
contribute to the debate by reading my msg06219 and writing to the
list what they do or don't like about it - and why.

  - Robin

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 18 Apr 2010 22:57:30 -0400

Having attempted to write documents that aptured points I thought were 
important, and having realized that the research group simply does not 
have agreement on the points, I do not see the purpose of writing 
something like what you describe.  Doing a good job on that takes work.
In the absence of agreement, there is no point in trying to publish 13 
or so visions.  At least not here.

Yours,
Joel

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

---

From: Robin Whittle <[email-masked]>
Date: Mon, 19 Apr 2010 14:26:57 +1000

Hi Joel,

> or so visions.  At least not here.

It does take work, but many participants must surely have opinions on
what the Recommendation would ideally be, according to their
understanding of the goals, constraints etc.  Those views have
resulted from a great deal of work reading RRG messages, proposal
documents - and for some, writing such messages and documents.  The
amount of work required to write these opinions up so others can know
and discuss them is small, I think, compared to the work many of us
have already put into this field.

I wasn't suggesting that we try to write something which we think
many people, or even a single other person, would agree upon.  I
suggest people write what they personally think would be a good
Recommendation, according to their own clearly stated set of goals.
Even if this is incomplete - such as only concerning a subset of the
proposals - I think this would be a better contribution to the field
than to write nothing.

 - Robin

---

From: [email-masked]
Date: Mon, 19 Apr 2010 02:42:19 -0400

I am not happy either with how things are handled.
Some suggestion:
It is great that every one my initiate a new subject line (thread). But: Threads pop up ... and disappear at any point in time. Without any fixed result.
Imho there should be individual threads as well as official threads (similar to individual and ietf- drafts). The official threads should have a clear focus and should also aim for a final result that we can refer to just like to RFCs.  And of course, every one may propose an official thread, but they should be initiated and managed by the chairs.
So far arguments are just shooted into the blue.

I am most critical versus the Anaheim decisisons too. But the looser isn't me (TARA), the looser will be the RRG by wasting 6 more years.

A second thing: We should respect each other.

Heiner

-----Ursprüngliche Mitteilung----- 
Von: Robin Whittle <[email-masked]>
An: RRG <[email-masked]>
Verschickt: Mo., 19. Apr. 2010, 4:32
Thema: [rrg] DIY Recommendations

  - Robin

---

From: Toni Stoev <[email-masked]>
Date: Tue, 20 Apr 2010 08:44:38 +0300

>                 Recommendation and/or by critiquing other people's

1. identity/location separation, for the sake of DNS, mobility, session management; done by introducing identifier.

---

From: Patrick Frejborg <[email-masked]>
Date: Tue, 20 Apr 2010 10:20:33 +0300

> 1. identity/location separation, for the sake of DNS, mobility, session management; done by introducing identifier.

52% of the Internet traffic is using HTTP, there you have a cookie
that can be used as a session identifier. MPTCP and SCTP have their
verification tag/token, these can be used as a session identifier.
I'm not that convinced that we need a generic identifier to solve the
routing issue - the mobility issue is more or less an application
issue, you have to take into account several factors such as low and
choppy bandwidth, the IP address might change etc. So the application
should use HTTP's cookie or leverage the transport protocols session
identifier.

With an identifier you can have the same checksum for the transport
protocol though your locator changes - but the reality is that there
is so much NAT out there that the Internet services no longer care if
the checksum of transport protocol changes.

Rendezvous services can be found for "free", e.g. Skype, pee-to-peer,
IM-services, SIP proxy/registrar etc
To use a generic identifier and to protect it from theft  you should
use DNSSEC, but that will come with an extra cost
http://www.networkworld.com/news/2010/032310-domain-name-registars-lagging.html
Will the average John Doe pay extra to protect his generic identifier
or use "free" identifiers that are bundled together with services he
uses??

Technically the locator/identifier separation is great, but I'm afraid
it isn't disruptive compared to the existing architecture we have -
think that MPTCP's token will just be good enough to provide mobility
for John Doe.

-- patte

---

From: Toni Stoev <[email-masked]>
Date: Tue, 20 Apr 2010 11:04:29 +0300

On Tuesday 20 April 2010 10:20:33 Patrick Frejborg sent:
...
> good enough to provide mobility
> for John Doe.

Patte, let us seek universal solutions.

---

From: Patrick Frejborg <[email-masked]>
Date: Tue, 20 Apr 2010 11:33:25 +0300

> Patte, let us seek universal solutions.

You might find Christensen's theorem interesting, especially the
low-end disruption part
http://en.wikipedia.org/wiki/Disruptive_technology

Still, this is not a critic against ILNP - it should be developed
because if IPv6 as such gets into DFZ we are in real trouble - so IPv6
should be toasted before it toasts the DFZ.

But it is not the only option, I don't think IPv4 is dead. When
depletion occurs the current 1,7 billion users will not disappear over
one night and you could do some nice things with a "good enough"
approach...

-- patte

---

From: Toni Stoev <[email-masked]>
Date: Tue, 20 Apr 2010 15:47:22 +0300

On Tuesday 20 April 2010 11:33:25 Patrick Frejborg sent:
...
> I don't think IPv4 is dead. When 

Actally the Internet has been too good.
If depletion occurs catching us not ready, the Internet will become good enough.