Mark Townsley wrote, on 08/21/2011 10:19 AM:
It takes me about 30 seconds to describe at a high-level what 4rd is to
someone
who already understands ds-lite by referring to it as a stateless version of
ds-lite. That's a good thing.
To someone who already understands 6rd:
4rd is to IPv4
On Aug 20, 2011, at 9:04 AM, Rémi Després wrote:
Le 20 août 2011 à 11:46, Mark Townsley a écrit :
On Aug 20, 2011, at 3:20 AM, Rémi Després wrote:
Le 20 août 2011 à 03:55, Mark Townsley a écrit :
...
we're already confused:
Le 20 août 2011 à 03:55, Mark Townsley a écrit :
On Aug 19, 2011, at 8:04 PM, Nejc Škoberne wrote:
Because of what RFC6333 says, suggesting NOW that solutions that don't need
NATs are variants of DS-lite is a sure way to confuse people.
Then we're already confused:
On Aug 20, 2011, at 3:20 AM, Rémi Després wrote:
Le 20 août 2011 à 03:55, Mark Townsley a écrit :
On Aug 19, 2011, at 8:04 PM, Nejc Škoberne wrote:
Because of what RFC6333 says, suggesting NOW that solutions that don't
need NATs are variants of DS-lite is a sure way to confuse
Mark,
Interesting definition of retronym.
It remains, though, that an analogue clock, the example given in the given
reference) is a clock variant (a device for measuring time).
A 4rd-encapsulation solution is in no way a DS-lite variant (built on a tunnel
to reach a CGN).
It would be nice,
Le 19 août 2011 à 03:08, Satoru Matsushima a écrit :
Hello Remi-san,
I've found this mail now.
On 2011/07/16, at 22:55, Rémi Després wrote:
Hi all,
1.
Being active in the IETF community has been overall enjoyable but, for
various personal reasons including financial,
I will no
2011/8/19 Rémi Després despres.r...@laposte.net:
I think so.
I know that some, although expressing nothing against the idea, would prefer
to wait and see.
I haven't heard so.
But others believe that, concerning the best way to structure drafts, the
earlier is the better.
IMHO, document
Le 19 août 2011 à 10:15, Satoru Matsushima a écrit :
2011/8/19 Rémi Després despres.r...@laposte.net:
I think so.
I know that some, although expressing nothing against the idea, would prefer
to wait and see.
I haven't heard so.
If I misinterpreted what I saw, that's even better.
But
Hi Satoru-san,
Please see my comments inline.
On 2011/08/18, at 18:08, Satoru Matsushima wrote:
Hello Remi-san,
I've found this mail now.
On 2011/07/16, at 22:55, Rémi Després wrote:
Hi all,
1.
Being active in the IETF community has been overall enjoyable but, for
various
Particularly when targeting the consumer appliance space, fewer documents are
better than many. Softwires should be working to converge on a single concise
and clear RFC for the stateless ds-lite mode of operation.
- Mark
On Aug 18, 2011, at 9:08 PM, Satoru Matsushima wrote:
Hello
+1.
The RFP angle is an important one, Simon.
Cheers,
Rajiv
Sent from Phone
On Aug 19, 2011, at 8:57 AM, Simon Perreault simon.perrea...@viagenie.ca
wrote:
On 2011-08-19 05:19, Tetsuya Murakami wrote:
draft-murakami-softwire-4rd
draft-murakami-softiwire-4v6-translation
I think it
When the RFP is coming from Best Buy for a consumer device, you want fewer
alternatives.
- Mark
On Aug 19, 2011, at 9:25 AM, Rajiv Asati (rajiva) wrote:
+1.
The RFP angle is an important one, Simon.
Cheers,
Rajiv
Sent from Phone
On Aug 19, 2011, at 8:57 AM, Simon Perreault
On 2011-08-19 11:21, Mark Townsley wrote:
When the RFP is coming from Best Buy for a consumer device, you want fewer
alternatives.
That's overly simplifying.
I would expect the standard bodies such as Cable Labs, BBF, 3GPP, etc.
to specify applicability of translation vs encapsulation to
Precisely. Fewer alternatives means cheaper, simpler hardware that is
ultimately required to run the software necessary to support the features. A
myriad of options whether complex or not, is not that.
--Tom
On Aug 19, 2011, at 11:21 AM, Mark Townsley wrote:
When the
Hi Marc,
I am having trouble to see how this thing could be stateless?
Also I don't see why we should, in view of NAT64 which is already standardized
and there are implementations, why not use it?
Of course no offense to my friend Xing Li.
Regards,
Behcet
Particularly when targeting the
Le 19 août 2011 à 17:11, Mark Townsley a écrit :
On Aug 19, 2011, at 5:17 AM, Rémi Després wrote:
Also, one of his slides has 4rd aka Stateless DS-lite. He knows, as you
know, that I had expressed strong opposition to this badly reductive view
(DS lite is hub and spoke, has no NAT in
[mailto:softwires-boun...@ietf.org] On Behalf
Of Rajiv Asati (rajiva)
Sent: Friday, August 19, 2011 6:26 AM
To: Simon Perreault
Cc: softwires@ietf.org
Subject: Re: [Softwires] 4rd mapping rule separation
+1.
The RFP angle is an important one, Simon.
Cheers,
Rajiv
Sent from Phone
On Aug 19, 2011, at 8:57
Dear Rémi,
Whether Encapsulation and Double-translation methods will remain in separate
drafts or might be regrouped in a single one including their comparison is, as
far as I am concerned, an open question (neither in favor nor against).
Not being in favor of a wide palette of different
Because of what RFC6333 says, suggesting NOW that solutions that don't need
NATs are variants of DS-lite is a sure way to confuse people.
+1
Nejc
___
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires
On Aug 19, 2011, at 8:04 PM, Nejc Škoberne wrote:
Because of what RFC6333 says, suggesting NOW that solutions that don't need
NATs are variants of DS-lite is a sure way to confuse people.
Then we're already confused:
http://tools.ietf.org/html/draft-boucadair-softwire-cgn-bypass-03
- Mark
On Aug 19, 2011, at 1:08 PM, Rémi Després wrote:
Le 19 août 2011 à 17:11, Mark Townsley a écrit :
On Aug 19, 2011, at 5:17 AM, Rémi Després wrote:
Also, one of his slides has 4rd aka Stateless DS-lite. He knows, as you
know, that I had expressed strong opposition to this badly
21 matches
Mail list logo
