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.)
That sounds great if the solution (eg. 4rd-U) is confirmedly feasible and extensively accepted by the group. Right? Best Regards, Leaf ________________________________ From: Rémi Després [[email protected]] Sent: Friday, May 04, 2012 20:55 To: Leaf yeh Cc: Jacni Qin; Ole Trøan; [email protected] Subject: Re: [Softwires] Result from the consensus call on Map vs 4rd-U and official way forward 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 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. 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.) Regards, RD Best Regards, Leaf From: [email protected]<mailto:[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]<mailto:[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]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/softwires
_______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
