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 to the motivation document, I failed to see the "mutually
exclusive" requirements were stated. Have we left it all behind or
chosen to miss it, since the mission to prove "stateless" approaches are
needed is complete?
Ok, let's wait for the output of the design team, while may I again
suggest that you consider seriously the mutually exclusive requirements
from E & T before moving forward?
Cheers,
Jacni
On 5/4/2012 Friday 6:08 PM, Leaf yeh wrote:
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 you go for the further
clarification or discussion on it here?
I would be open to accept these 2 solutions, which share part of the
same address format. And let the operator get the right to pick one he
believe it is feasible & suitable, or even not pick any of these solution.
Best Regards,
Leaf
*From:*[email protected] [mailto:[email protected]]
*On Behalf Of *Jacni Qin
*Sent:* Friday, May 04, 2012 10:03 AM
*To:* Ole Trøan
*Cc:* [email protected]
*Subject:* Re: [Softwires] Result from the consensus call on Map vs
4rd-U and official way forward
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 that an implementation supported both, and
making this purely into an operational choice?
I'd rather prefer you pick one only.
wouldn't we all. I think you're flogging a dead horse. let us accept that the requirements for translation and the requirements for encapsulation are mutually exclusive.
We put the requirements on the table and some discussions, but sorry,
I can't remember what exactly the consensus/conclusion is, and I'm
confused about where we are.
I see, maybe I'm wrong, the technical requirements are drawn more from
the two incompatible solutions after, but not from the
conversion/analysis of the statements in "motivation", then we got the
mutually exclusive ones you mentioned above. How can we figure out the
way to move forward? Just by some MUSTs/MAYs ...
Anyway, if generally we have a single target or design goal, IMHO,
it's really a bad idea to keep parallel two, no matter we call them
requirements/solutions, whatever.
Cheers,
Jacni
cheers,
Ole
_______________________________________________
Softwires mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/softwires
