It seems that we have to subscribe v4tov6transition@ietf.org individually.//Fwd: Bounce action notification

2 views
Skip to first unread message

Tina TSOU

unread,
Aug 21, 2010, 10:24:44 AM8/21/10
to v4tran...@googlegroups.com

Begin forwarded message:

Date: August 21, 2010 9:25:08 PM GMT+08:00
Subject: Bounce action notification

This is a Mailman mailing list bounce action notice:

   List:       v4tov6transition
   Member:     v4tran...@googlegroups.com
   Action:     Subscription disabled.
   Reason:     Excessive or fatal bounces.



The triggering bounce notice is attached below.

Questions? Contact the Mailman site administrator at mai...@ietf.org.

From: Mail Delivery Subsystem <mailer...@google.com>
Date: August 21, 2010 9:20:28 PM GMT+08:00
Subject: Delivery Status Notification (Failure)


Hello v4tov6transi...@ietf.org,

We're writing to let you know that the group you tried to contact (v4transition) may not exist, or you may not have permission to post messages to the group. A few more details on why you weren't able to post:

* You might have spelled or formatted the group name incorrectly.
* The owner of the group may have removed this group.
* You may need to join the group before receiving permission to post.
* This group may not be open to posting.

If you have questions related to this or any other Google Group, visit the Help Center at http://groups.google.com/support/?hl=en_US oogle Groups



----- Original message -----

Received: by 10.142.147.20 with SMTP id u20mr662547wfd.48.1282396828419;
       Sat, 21 Aug 2010 06:20:28 -0700 (PDT)
Received: by 10.142.147.20 with SMTP id u20mr662546wfd.48.1282396828379;
       Sat, 21 Aug 2010 06:20:28 -0700 (PDT)
Return-Path: <v4tov6transi...@ietf.org>
Received: from mail.ietf.org (mail.ietf.org [64.170.98.32])
       by gmr-mx.google.com with ESMTP id u29si5273714wfh.4.2010.08.21.06.20.28;
       Sat, 21 Aug 2010 06:20:28 -0700 (PDT)
Received-SPF: pass (google.com: domain of v4tov6transi...@ietf.org designates 64.170.98.32 as permitted sender) client-ip=64.170.98.32;
Authentication-Results: gmr-mx. gle.com: domain of v4tov6transi...@ietf.org designates 64.170.98.32 as permitted sender) smtp.mail=v4tov6transi...@ietf.org
Received: from [127.0.0.1] (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 40F513A6816;
Sat, 21 Aug 2010 06:19:53 -0700 (PDT)
X-Original-To: v4tov6tr...@core3.amsl.com
Delivered-To: v4tov6tr...@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 91C0A3A6811
for <v4tov6tr...@core3.amsl.com>;
Sat, 21 Aug 2010 06:19:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.342
X-Spam-Level:
X-Spam-Status: No, score=-102.342 tagged_above=-999 required=5
tests=[AWL=0.257, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32])
by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id AR0nE4HDdWDy for <v4tov6tr...@core3.amsl.com>;
Sat, 21 Aug 2010 06:19:51 -0700 (PDT)
Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 621683A657C
for <v4tov6tr...@ietf.org>; Sat, 21 Aug 2010 06:19:51 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1])
by p130.piuha.net (Postfix) with ESMTP id 26B862CC9A;
Sat, 21 Aug 2010 16:20:21 +0300 (EEST)
X-Virus-Scanned: amavisd-new at piuha.net
Received: from p130.piuha.net ([127.0.0.1])
by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id ACQStfajDFpH; Sat, 21 Aug 2010 16:20:20 +0300 (EEST)
Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130])
by p130.piuha.net (Postfix) with ESMTP id EC19D2CC62;
Sat, 21 Aug 2010 16:20:18 +0300 (EEST)
Message-ID: <4C6FD292...@piuha.net>
Date: Sat, 21 Aug 2010 09:20:18 -0400
From: Jari Arkko <jari....@piuha.net>
User-Agent: Thunderbird 2.0.0.24 (X11/20100411)
MIME-Version: 1.0
To: Cameron Byrne <cb.l...@gmail.com>
References: <018544C5-8D1E-412A...@cisco.com> <AANLkTimo-w_EPr_G=FEawD3FMkwwAr...@mail.gmail.com> <AANLkTiniY0-6MWjTHBmf3...@mail.gmail.com> <1E46BEA0-85C4-44B0...@cisco.com> <AANLkTin07FJhQ7=FCSXLtGc1yvKvwJ9jm5=WZie...@mail.gmail.com> <ACBBEBCE-08AA-4D14...@cisco.com>
<AANLkTimfhx-TMZFXOtXw4...@mail.gmail.com>
In-Reply-To: <AANLkTimfh roAk+...@mail.gmail.com>
Cc: IPv6 v6ops <v6...@ops.ietf.org>, v4tov6tr...@ietf.org
Subject: Re: [v4tov6transition] draft-arkko-ipv6-transition-guidelines WGLC
X-BeenThere: v4tov6tr...@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <v4tov6transition.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/v4tov6transition>,
<mailto:v4tov6transi...@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v4tov6transition>
List-Post: <mailto:v4tov6tr...@ietf.org>
List-Help: <mailto:v4tov6transi...@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v4tov6transition>,
<mailto:v4tov6transi...@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: v4tov6transi...@ietf.org
Errors-To: v4tov6transi...@ietf.org

Cameron,

Jari states IPv6-only works well for
mobile.  I believe one )  states it
approaches 100% functionality.


Yes, though for the record, draft-arkko-ipv6-only-experience does say
that under certain assumptions (the ability to pick the right user
devices) you reach 100% functionality.

I do believe that IPv6-only (with nat64) is an excellent approach for
mobile networks, and I hope we will soon see this in widespread
commercial usage. Perhaps in your network :-)

That being said, I do not want to give the impression that its a piece
of cake either. The assumption above is a tough requirement, and for
sure there'll be plenty of other work ahead as well. I do stand by my
recommendation that *at this time* even for mobile operators, dual stack
should be the default strategy even if some networks are going for
IPv6-only. I am aware of the additional complexities on the dual stack
side as well. In a few years down the road the
recommendation will be different, i.e., enough software and user
equipment have matured so that IPv6-only can be considered as the
default strategy. Of course, some networks have to be at the forefront.
They will be the leaders, but will also get the initial pains from
hitting various issues first.

Anyway, what are we really discussing here about? The document *does*
recommend all four different models. I think we do have deployment
evidence that speaks in favor of dual stack being the most problem free
(at the moment), so this is why it is discussed first and described as
the default strategy. I would be happy to use more accurate or different
wording, but I don't think that you are arguing either that some of the
models should go away. Would you like us to add something more specific
about types of networks (e.g., mobile) where translation-based model is
recommended?

Jari

________ ______________
v4tov6transition mailing list
v4tov6tr...@ietf.org



Reply all
Reply to author
Forward
0 new messages