Comment: PIm Sparse Mode to Proposed
Sam Hartman <hartmans-ietf@mit.edu> Thu, 27 October 2005 15:19 UTC
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EV9XA-0008VR-TH; Thu, 27 Oct 2005 11:19:16 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EV9X8-0008UY-6N; Thu, 27 Oct 2005 11:19:15 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13123; Thu, 27 Oct 2005 11:18:57 -0400 (EDT)
Received: from carter-zimmerman.dyn.mit.edu ([18.188.3.148] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EV9kV-00088N-PB; Thu, 27 Oct 2005 11:33:04 -0400
Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 1FBE9E0038; Thu, 27 Oct 2005 11:19:19 -0400 (EDT)
To: iesg@ietf.org
From: Sam Hartman <hartmans-ietf@mit.edu>
Message-Id: <20051027151919.1FBE9E0038@carter-zimmerman.mit.edu>
Date: Thu, 27 Oct 2005 11:19:19 -0400
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4
Cc: ietf@ietf.org
Subject: Comment: PIm Sparse Mode to Proposed
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org
[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@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
- Comment: PIm Sparse Mode to Proposed Sam Hartman
- Re: Comment: PIm Sparse Mode to Proposed Pekka Savola
- RE: Comment: PIm Sparse Mode to Proposed Gray, Eric
- Re: Comment: PIm Sparse Mode to Proposed Sam Hartman