Re: [RRG] Conceptual vs. specific - another discussion list?

[Robin Whittle <rw@firstpr.com.au>]

My first message in this thread concerned moving one set of
discussions to another list, such as the RAM list or some newly
created one:

  Discussion about the architecture which involved too much
  focus on potential solutions - particularly the engineering and
  deployment details - to be compatible with the current scope of
  the RRG list.

Now there are some other lines of discussion which might be
inappropriate for the RRG list, due to the rough consensus reached on:

   Our recommendation should be applicable to IPv6.  It may or
   may not also apply to IPv4, but at the very least must provide
   a path forward for IPv6.

  http://psg.com/lists/rrg/2008/msg01417.html    2008-06-06
  http://psg.com/lists/rrg/2008/msg01535.html    2008-06-13

Lixia and Tony, does this mean that it would be out of scope to have
even high-level architectural discussions concerning a potential
solution which would be applied soon to IPv4 and later to IPv6?

Likewise, does this mean that discussions about migration of large
numbers of users to IPv6, or to a future significantly modified
version of IPv6, are out of scope?  My guess is they would be, and
would disrupt the discussions you want to focus on.


Can you clarify the scope of the RRG discussions, including with
some examples?  I have a feeling that quite a lot of recent threads
which I and others want to continue to discuss are outside the RRG
scope, which you alone decide.

Is it possible for you to organise a separate IRTF discussion list
and appoint someone to moderate it?  I guess you don't want to be
responsible for two lists.

I think the scope of the RRG list you want for now - and perhaps
until 2009-03 - is narrower than the full scope of the RRG charter:

   The RRG will have an open general discussion mailing list where
   any topic of interest to the routing research community can be
   discussed, and topics related to scalable routing architectures
   are particularly encouraged.

Some people interpret "research" as not involving engineering.
However, this is an engineering field.  This is not science, such as
astronomy or biology, which are concerned purely with understanding
the processes of Nature.

This is research into network engineering - prior to the engineering
task of the IETF creating final protocols, standards etc. to
implement a specified architecture.

I understand you need to restrict the scope of the RRG list to make
the progress you aim for.  Other discussions can take place
according to the next part of the Charter:

   For specific topics with widespread discussion, interested
   parties will be encouraged to form ad-hoc mailing lists, with
   summaries sent to the general mailing list quarterly. Summaries
   will contain the recent conclusions reached as well as the
   near-term agenda for future progress.


Some RRG-related matters are being discussed now on ARIN-PPML.  See
below my signature for two examples.

However, I think PPML is not the best place to continue the routing
and addressing architecture discussions which don't belong on the
RRG list.

Do you suggest the RAM list be used for this?

If not, maybe someone can set up a list with public archives.

In mid-July I could set up Mailman and an archive on
www.firstpr.com.au (the server is in Dallas - Fort Worth) or I could
create a separate domain for it, such as: radiscuss.net

It would probably be better if the list was run by someone else -
someone not so directly involved in the discussions - since that
person needs to make the final judgement about what was on topic,
what was reasonable or a flame etc.  Also, an IRTF list would
probably have a more permanent archive.

There is always Yahoo Groups, but that is ad-infested and not
necessarily a secure or easy to use archive.  The first message from
each member needs to be held for moderator approval to prevent spam.

  - Robin


Recent PPML discussions:

  http://lists.arin.net/pipermail/arin-ppml/

     Alain Durand's Comcast "464" plans are of interest to the
     question of adoption of IPv6-only services, which I think the
     RRG rough consensus involves some assumptions about.  464
     uses the IPv6 access network to tunnel IPv4 packets to a
     special kind of NAT.  The result is each customer gets their
     own private IPv4 address space (such as 192.168/16) and has a
     single layer of NAT in the remote NAT box.  Manual port
     forwarding cannot be supported, so uPnP IGD can't be used -
     with consequent impact on P2P and probably other apps.
     So this would not really be an IPv6-only service - for most
     users it would be a NATed IPv4 service like what they get now,
     but without the possibility of grabbing a port to receive
     packets from a stable public IPv4 address.

     Also, several folks on PPML with long experience support the
     statement which we have just formed rough consensus on.



--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg