Le 2012-05-04 à 12:08, Leaf yeh a écrit :
Jacni - Anyway, if generally we have a single target or design goal,…
There are many design goals here. What Ole said in this email is the solution
of Encapsulation Translation will meet the different ones, which sounds
mutually exclusive. Will
2012-05-04 18:16, Leaf yeh:
Remi - Would you agree, though, that if a solution is confirmed to cover
design goals of both Encapsulation and Translation, it would better meet the
WG objective objective to have a single standard? (Operators would be
relieved from having to make a choice.)
I'll be open to accept N solutions, in case of necessity.
Of course, operators get the right to pick one, e.g. from DS-Lite,
stateless like MAPs/4rd .., etc., but it'll be our fault to let them
try to pick one from different variables of the stateless, if there's
no sufficient reason.
Back
Ole,
On Thursday, May 03, 2012 2:58:35 PM, Ole Trøan wrote:
Jacni,
My concern is MAP isn't a single solution. Operators still need to make a
choice between E and T because they are not compatible.
would it alleviate your concerns if the documents had MUSTs for both? i.e.
increasing the
2012-05-03 à 10:38, Ole Trøan:
...
let us accept that the requirements for translation and the requirements for
encapsulation are mutually exclusive.
Agreed: each of E or T doesn't cover by itself all expressed requirements for a
stateless 4via6 solution.
The question that remains, however,
Ole,
On 5/3/2012 Thursday 4:38 PM, Ole Trøan wrote:
Jacni,
My concern is MAP isn't a single solution. Operators still need to make a
choice between E and T because they are not compatible.
would it alleviate your concerns if the documents had MUSTs for both? i.e.
increasing the probability
Re-,
On 4/30/2012 Monday 4:03 AM, Lee, Yiu wrote:
Well, even the WG decided to go with MAP, we would still need to coin toss
between MAP-T and MAP-E, wouldn't we?
May I share your concern.
Cheers,
Jacni
On 4/26/12 10:50 AM, Jan Zorz @ go6.sij...@go6.si wrote:
On 4/26/12 11:50 AM, Mark
My concern is MAP isn't a single solution. Operators still need to make a
choice between E and T because they are not compatible.
From: Jacni Qin ja...@jacni.com
Date: Wednesday, May 2, 2012 9:03 PM
To: Yiu L. LEE yiu_...@cable.comcast.com
Cc: Jan Zorz @ go6.si j...@go6.si, softwires@ietf.org
Re-,
On 5/3/2012 Thursday 10:18 AM, Lee, Yiu wrote:
My concern is MAP isn't a single solution. Operators still need to
make a choice between E and T because they are not compatible.
Fully agree, and IMHO, there have been lots of compromise in the design
of MAP algorithm to accommodate both E
Well, even the WG decided to go with MAP, we would still need to coin toss
between MAP-T and MAP-E, wouldn't we?
On 4/26/12 10:50 AM, Jan Zorz @ go6.si j...@go6.si wrote:
On 4/26/12 11:50 AM, Mark Townsley wrote:
Perhaps we would have been better off with the coin toss.
+1
bingo.
Cheers, Jan
Chairs, ADs,
I regret this decision. *Whatever* the results of the poll, your text below
explicitly suggests a discrimination between voters.
Basically, you seem to distinguish between people who are entitled to vote
because they have supposedly participated to the stateless specification
Dear all,
I personally regret this decision and reject the justifications provided. If
you don't want people to contribute and express their opinion, it is easy: make
it a close community.
If you insist to ignore what expressed the majority of individuals who
participated to the poll, may I
Because of the history of MAP and 4rd-U, we will designate independent teams
of volunteer reviewers to advise the working group about the state of the
document sets. Each set will be reviewed by an independent team who are not
authors of the MAP and 4rd-U documents. Each review team will
I'm new to the group, but I made my vote because I have studied both
solutions. I was unable to find any running code for 4rd-U that I could
test and verify, while I was able to do that with MAP.
I voted based on the quote about the IETF from David Clark: We reject
kings, presidents and voting.
On 4/26/12 11:50 AM, Mark Townsley wrote:
Perhaps we would have been better off with the coin toss.
+1
bingo.
Cheers, Jan
P.S: I'll not waste more bits on this topic as it's apparently a waste
of bandwidth :)
P.P.S: Should we deprecate RFC6346?
Hi Jan,
P.P.S: Should we deprecate RFC6346?
A+P is in MAP T, MAP E and 4rd-U. I don't understand why you are
worried about it?
Having said that I for one think that A+P should be restricted to the CPEs.
Otherwise you are creating another NAT.
Regards,
Behcet
The chairs and ADs met to look at the results of the consensus call that ended
Wednesday and decide the way forward.
First, we would like to offer a couple observations on the raw results from the
consensus call:
- We had a number of people responding more than once, sometime with different
17 matches
Mail list logo
