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
