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

Reply via email to