Fully agree with Maoke! This is not just the issue of publishing two documents.......To accormodate with 4rd-U, many existing RFCs should be updated, like RFC 4291,RFC6052,etc. There is no evidence to show that we need to do that because 4rd-U havn't been shown that it is workable in today's Internet.
Congxiao 2012/4/4 Maoke <fib...@gmail.com> > 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 > >
_______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
