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(_at_)ietf(_dot_)org
[mailto:ietf-bounces(_at_)ietf(_dot_)org] On Behalf Of
Stephen Kent
Sent: Montag, 10. Oktober 2011 21:41
To: ietf(_at_)ietf(_dot_)org
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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf