Behcet,
If you are suggesting we need get rid of multicast capabilities and use unicast
between the AFTR and B4, I still claim this is a bad design choice. The
rationale for the design documented in the draft is as follows (excerpt from
the draft):
If customers have to access IPv4
Re-,
Did you read draft-ietf-softwire-dslite-multicast?
I have some doubts given your message below.
Cheers,
Med
-Message d'origine-
De : Behcet Sarikaya [mailto:sarikaya2...@gmail.com]
Envoyé : lundi 11 juin 2012 18:08
À : BOUCADAIR Mohamed OLNC/NAD/TIP
Cc : softwires@ietf.org;
Re-,
Please see inline.
Cheers,
Med
-Message d'origine-
De : liu dapeng [mailto:maxpass...@gmail.com]
Envoyé : mercredi 13 juin 2012 12:09
À : BOUCADAIR Mohamed OLNC/NAD/TIP
Cc : softwires@ietf.org
Objet : Re: [Softwires] I-D Action:
I think what Dapeng wants to convey would be achieved if you changed the
may to will typically:
... state will typically exist in the customer premises side
Is this acceptable?
On the second point, I agree with the existing text.
Tom Taylor
On 13/06/2012 7:42 AM,
Effective today, I'm stepping down from the position of Softwire wg co-chair.
I'd like to thank all of you that have been participating to this working group
since its
creation in 2006. A lot of very good work came out it.
Ralph Droms, our AD, has started the process to find a replacement.
I prefer Tom suggestion. It is typical to have a NAT but not a must or
should.
On 6/13/12 12:38 PM, liu dapeng maxpass...@gmail.com wrote:
I can change may to should to
please you but it really does make sense.
= thanks
smime.p7s
Description: S/MIME cryptographic signature
Hi Tom,
Thank for the proposal. I can update the text with your proposed wording if
Dapeng is OK.
Dapeng, are you happy with the text proposed by Tom?
Cheers,
Med
-Message d'origine-
De : Tom Taylor [mailto:tom.taylor.s...@gmail.com]
Envoyé : mercredi 13 juin 2012 17:44
À :
