Hi, This is good input and made me realize what I disliked in the document which made me oppose to its publication. People (rightfully) pressed on the significance of the document to be about a general principle - one solution to any given problem. The IETF, _without_ external help, has a history of going down this road. Nobody stood up to stop that. Nobody wrote such a document then. Why now? Turf war, not invented here syndrome? I think it doesn't really matter. What would make my opposition go away is if we could write a more general document in which we point our own failings in the past, take this current issue into consideration and make it clear - in general - that the IETF is committed to follow this general principle more strictly in the future. _That_ would be a useful document and one which I would support. And it would be good if we could have such kind of pushback for multiple solutions in the future. WG chairs can take this document, show it to their WG and say "Guy s, this is a guiding IETF principle. Get your act together and come up with a single solution. We will not have two or more.". Just ranting about this particular case is not helpful with all the multi-solutions we have created ourselves. Best, Rolf NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 > -----Original Message----- > From: ietf-bounces@xxxxxxxx [mailto:ietf-bounces@xxxxxxxx] On Behalf Of > Stephen Kent > Sent: Montag, 10. Oktober 2011 21:41 > To: ietf@xxxxxxxx > Subject: Re: Last Call <draft-sprecher-mpls-tp-oam-considerations- > 01.txt> (The Reasons for Selecting a Single Solution for MPLS-TP OAM) > to Informational RFC > > I support this doc, and concur with Stewart's comments. > > Contrary to what some have suggested, we sometimes (ofttimes?) have > more than > one standard for no good technical reason. Sometimes very large, > competing companies back different standards for parochial reasons, > to the detriment of consumers, service providers, etc. This appears > to be one of those cases. Moreover, not opposing a two-standard > approach sends a bad message, and encourages similar, bad behavior in > the future. > > As the co-chair of PKIX, which has two standards for cert management > (CMC and CMP), for exactly the bad reasons I cite above, I am > intimately familiar with this sort of problem. I failed, in my role > as PKIX co-chair, to prevent this in that WG. Let's not repeat that > sort of mistake here. > > Steve > _______________________________________________ > Ietf mailing list > Ietf@xxxxxxxx > https://www.ietf.org/mailman/listinfo/ietf _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf