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 [EMAIL PROTECTED] 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
