well, i cannot help but send out this late Apr-1 joke: let's see what is the problem publishing the two document plus an informational doc analysing what problems 4rd-u introduces to architecture and real operation, with them all stable and having an RFC number for each? if this is fine, we all could be happy and the peace comes. lol
a serious point not of the Apr-1 joke: as an IETF WG, we are obliged to provide surely high-quality document to the market. even we believe market choice, at least we have to publish what we ourselves have well understood, carefully coded and well tested. otherwise, the market would see IETF more of a group of doc-makers rather than technology-explorers. - maoke ---- - we reject kings, presidents, and voting... - Rex redivit. vive le Roi. 2012/4/3 Marc Blanchet <marc.blanc...@viagenie.ca> > well, let's see the other way around: what is the problem of publishing > the two documents now?So that they are stable and have a RFC number. Then > any implementer can implement based on the RFC. Providers can request their > manufacturers to have a product which conforms to the RFC. > > Marc. > > Le 2012-04-03 à 14:56, Wojciech Dec a écrit : > > The irony is that this is an apples and oranges comparison, and throwing > away ripe apples into some box with raw oranges looks rather unfair. > > Some of the of the indicators are: > - MAP is not only the result of a consensus of a broad WG design team, but > also that of numerous authors of the merged drafts whihc have been > discussed for 1 year+. The 4rd-u technical proposals were evaluated by the > design team, and have not gained support there. > - MAP running code exist > - 4rd-U covers a technical corner case that is "self created" (if not self > invented/motivated) > - 4rd-U does not allow v4-v6 communication (say a v4 host to a v6 sign-up > portal, etc) > - 4rd-U is not by any means "universal". As admitted it requires the > coupling with BIH, which features the same technical corner case that 4rd-u > claims to solve (doh). > > The other aspect is that some different measure appears to be being > applied in this selection *for WG adoption* vs the selection of the other > drafts in softwire, which have gained WG draft status without even a shred > of running code. > > -Woj. > > On 3 April 2012 18:32, Marc Blanchet <marc.blanc...@viagenie.ca> wrote: > >> I don't see a way out of this thread. >> >> my suggestion: >> - published both as experimental >> - let the market decide >> - come back later to move one or the other standard track. >> >> Above all, I think having a stable specification (i.e. RFC) that >> implementers can code against and providers to require is what is needed >> first. >> >> Marc. >> >> Le 2012-04-03 à 11:14, Jan Zorz @ go6.si a écrit : >> >> > Dear Softwires WG chairs. >> > >> > For how long will you leave this useless cockfight go on instead of >> steering the working group into a direction, that may enable us to decide >> on something and chose the direction? >> > >> > We are running in circles here and just amplificating the noise, coming >> from certain usual suspects. >> > >> > Cheers, Jan >> > >> > P.S: I too enjoy observing the roosters fight, but I don't think we >> have time for this now. :) >> > _______________________________________________ >> > 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 >> > > > > _______________________________________________ > 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
