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: softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] On > Behalf Of Jacni Qin > Sent: Friday, May 04, 2012 10:03 AM > To: Ole Trøan > Cc: softwires@ietf.org > 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 > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires
_______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
