On Fri, Jul 17, 2015 at 1:34 AM, Stephen Farrell <[email protected]> wrote:
> > Hiya, > > I see a lot of folks preferring option 1 which is basically > to wait and see if some magic pixie dust appears before November > that causes the WG to achieve rough consensus for one approach > over the other. > > I think wait and see is the wrong characterization; the proposal is to work on both. If one gets worked on more than the other, that is signal that it should get more review and effort from the rest of the IETF. If that review shows flaws, we can correct them at that point (by shifting to the other proposal if need be, or just fixing them in situ, since there's already a lot of borrowing). (I would personally be okay with the option "Assume you will raise two siblings", and require that the working group come up with an overall way to support new methods as they arise, as a form of agility in this space. The current situation then becomes a worked example. I understand the contrary vision is "single basket, watched carefully", but it's not the only vision). > The WG have failed to choose a *startung point* a couple of > times now and all that will happen in the next 4 months (including > holidays) is that the two proposals will be slightly harder to > separate since the authors will inevitable try adopt the strengths > of the alternative proposal where possible and mitigate whatever > has been seen as a weakness in their own proposal. I have seen > this pattern a number of times in the IETF and it has always > ended badly that I've seen. This one seems to me to be ending > similarly badly, sadly. > > > Can someone explain why I'm highly likely to be wrong and just > what pixie dust will magically appear here and help over the > long hot summer? (During which many sensible folk will go away > for a month.) > > If we actually do work, instead of marvel at the difficulty of picking a pretty baby, the dust for each proposal might get ground finer, letting us choose? > IMO, option 1 == more pointless prevarication. Closing the WG > now or letting Martin pick now are the only sensible choices IMO. > > I think asking the AD to pick is more sensible in cases like > this since regardless of which *starting point* is adopted, the > WG will get to change that however they like before the process > is done. I don't think this is within the IETF process. The IESG could revise the charter to name a starting point, but the revision would go through the usual community review. You could also use RFC 3929, since the community agreed to that experiment, and after the working group consensus to use it name the AD as the one doing qualified short-straw selection, but I think it would be cleaner to have someone not in the appeals chain for this decision. > We are not doing an IETF LC here, we're supposed to be > deciding which *starting point* to work from, more than a year > after we should have gotten that done. I also don't see any need > for RFC3929 stuff here, nor do I think that is suited for cases > like this at all. IMO Martin can decide based on his take on > the reasonable set of technical arguments already made, none of > which are really "winning." > > Frankly, I think the unwillingness to choose-and-make-progress > in this WG is demonstrating the IETF at it's near worst. (And > yes, this is written in irritated-by-that mode;-) > > As the rtcweb experience shows, it can be very frustrating, but compromises can also emerge. Ted > S. > > > _______________________________________________ > Tcpinc mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/tcpinc >
_______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
