Sam, There can be some drawbacks to mandating that implementations must include the "XYZ security" protocol. For example, there may be some niche deployment opportunities with a trust model that does not need any form of security and implementations may be tailored for those deployments by simply omitting the "mandated" security mechanism. In this situation, the "XYZ security" protocol will come to be directly associated with a certain cost that users may not be willing to pay in every case and - so - it will be omitted in at least some cases. Or it may turn out that another security mechanism is preferred by the user community, and they request suppliers to include that mechanism - in lieue of "XYZ". In both cases, you end up with interworking implementations that do not conform to the standard - establishing a de facto standard and making the defined standard irrelevant. On the other hand, if folks think that the "ABC Security" protocol is sufficient and would be used if people knew how to use it, then adding an explanation of how to use the "ABC Security" protocol could very well have the same net result as mandating it - only without the embarrasment of having defined an irrelevant standard as a result of over-specification. -- Eric --> -----Original Message----- --> From: ietf-bounces@xxxxxxxx --> [mailto:ietf-bounces@xxxxxxxx]On Behalf Of --> Sam Hartman --> Sent: Thursday, October 27, 2005 11:19 AM --> To: iesg@xxxxxxxx --> Cc: ietf@xxxxxxxx --> Subject: Comment: PIm Sparse Mode to Proposed --> --> --> --> [IETf, the following is a ballot comment on the PIM Sparse Mode --> document which is before the IESG today. This is not a --> discuss: I am --> not holding the document until this issue is fixed. I do not expect --> the authors to address my comment, but I do ask the community to --> consider the issue.] --> --> This comment is not a discuss, but I am certainly not thrilled with --> the current situation. This document does not define a mandatory to --> implement security mechanism. It does tell network --> administrators how --> to use IPsec to secure PIM. --> --> That's not really enough for several reasons. First, it does not --> require the necessary features of IPsec be implemented --> along side PIM. --> Second, it provides a reasonably bad user experience: the --> user has to --> use a general mechanism that doesn't know about PIM not one --> that knows --> about PIM. So the user has to encode all the information about PIM --> and its traffic flows for the general mechanism. --> Unfortunately it is --> probably not as simple as having vendors provide easy configuration --> tools. While a vendor could do that for their own --> products, the user --> has enough flexibility in how they configure things that --> such a vendor --> would not be guaranteed to work with other products or arbitrary --> sites. --> --> So I'm not going to block this document. However we must --> do better in --> the future. The primary purpose of this comment is to say that I'm --> not happy with this direction and that the fact that this document --> passes IESG review may not be used as a justification that --> future work --> should be allowed through. --> --> --> I would certainly hold work started today to a higher --> standard. This --> document would also get a discuss because it has no mandatory --> automated key management if it were new work. --> --> We will have to work on what scale is appropriate for work --> already in --> progress. --> --> --> On a more positive note, I'd like to thank the authors for a really --> well written document. I wish all the specs I had to review were of --> this quality. --> --> _______________________________________________ --> Ietf mailing list --> Ietf@xxxxxxxx --> https://www1.ietf.org/mailman/listinfo/ietf --> _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf