Summary of ISMS chartering discussion
Sam Hartman <hartmans-ietf@mit.edu> Thu, 29 September 2005 01:03 UTC
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKmq7-0007S9-Eu; Wed, 28 Sep 2005 21:03:59 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKmq5-0007Rz-Sz for ietf@megatron.ietf.org; Wed, 28 Sep 2005 21:03:57 -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 VAA25542 for <ietf@ietf.org>; Wed, 28 Sep 2005 21:03:56 -0400 (EDT)
Received: from stratton-four-o-two.mit.edu ([18.187.6.147] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EKmxe-0001Hb-Ln for ietf@ietf.org; Wed, 28 Sep 2005 21:11:47 -0400
Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 4237FE0049; Wed, 28 Sep 2005 21:03:54 -0400 (EDT)
To: ietf@ietf.org
From: Sam Hartman <hartmans-ietf@mit.edu>
Date: Wed, 28 Sep 2005 21:03:54 -0400
Message-ID: <tslr7b84rd1.fsf@cz.mit.edu>
User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 43317e64100dd4d87214c51822b582d1
Subject: Summary of ISMS chartering discussion
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
The following summary was sent to the ISMS list. It has received no comment. In related news, Eliot is working with several people to explore the call home option within the O&M community.
--- Begin Message ---Hi. We had a very productive review of the ISMS charter on the ietf list. Here's my response and action plan going forward on that issue. Based on comments on the list here, comments to the ietf list, numerous phone calls/jabber sessions and in-person discussions I believe everyone will be able to move forward with this proposal. If there are problems let me know and we'll see what we can do. Included in this message: * Review of IETF Discussion * IESG Decision and AD Comments * evaluating Extensibility of ISMS Output Review of IETf Discussion There was significant interest in considering firewall and NAT traversal for SNMP and for broader management applications. Several people pointed out why this is more involved than just specifying extensions to the ISMS ssh draft. Several people said they believed that the actual extensions to the ISMS drafts are simple. There was rough consensus that it would be a bad idea to produce ISMS specifications that did not even enable firewall/nat traversal and then later decide that this traversal was an important extension to the SNMP architecture. However there was also a rough consensus that ISMS need not block on the decisions about whether to implement traversal or about the specific architectural issues. A few people did raise the concern that having two standards come out requiring products to be updated first for ISMS and then later for traversal would be undesirable. However the rough consensus was that these efforts need not block each other. I make no consensus call on whether there is a consensus in the SNMP community to extend SNMP to support firewall and NAT traversal. That's a call I'm not qualified to make and one that needs to be made by the O&M ADs. In addition that decision needs to happen within the O&M area. I didn't see a specific charter text proposal change. There was something reasonably close I believe from David Nelson proposing that we add something about considering call home in the design of ISMS to the charter. While there was support for this consideration expressed both on the ietf list and the isms list, there was not a rough consensus that charter changes are required. Summary of IESG Decision and AD Comments The IESG has approved the ISMS charter with no modifications. The announcement will come out as soon as I find a chair to replace Ken. Chairs and participants should move forward under the new charter. For example it would be reasonable for the chairs to approve documents that meet charter deliverables. However it is important that we consider the firewall and nat traversal issues in our design of the ISMS architecture. In particular we should consider firewall and nat traversal as a possible extension to ISMS. It is desirable that we be able to accommodate such an extension with the protocols we design. Similarly we should follow the discussion of this extension in the O&M area. If the O&M area decides to extend SNMP in this direction and completes the appropriate architectural work, then we will need to support firewall and nat traversal in our protocol. That said, there are two things we must not do. First, we cannot standardize firewall and nat traversal in the ISMS protocol without a normative reference to a specification for how it works in SNMP. It's not a good idea for devices to be saying "manage me," without an SNMP architecture that provides for configuration of this functionality and for well defined semantics. In other words, we can enable traversal as an extension, we can have an extension ready to plug into the document and we can plug in that extension if the SNMP community gives us the architectural framework to reference. we cannot plug in the extension before that happens and we will not wait if we're done and the SNMP community is still working on the issue. Also, if the SNMP community decides that they are not interested in firewall/nat traversal we will spend much less time on it. The other thing we must not do is allow firewall and nat traversal to block our progress. If we get to a situation where we have a rough consensus if we ignore firewall and nat traversal, but we are unable to efficiently form a consensus while considering firewall and nat traversal, then we move on ignoring firewall and nat traversal for that issue. Things do change if the SNMP community formally decides to implement firewall and nat traversal for us. If that happens, then parts of firewall and nat traversal may be blocking issues for us. In addition, some of the people arguing for solving the traversal problem believe that working on the architectural extensions within ISMS might be reasonable. This would require a charter revision, but I would not object to such a charter revision if the right people were following ISMS and if it had sufficient O&M support. I also would not object to doing the work elsewhere. Evaluating Extensibility of ISMS Extensibility of protocols is an important evaluation criteria. When looking at the ISMS output, I will look at how easy it would be to add likely extensions to the protocol. Is there sufficient capability negotiation? Can we add fields, messages or functionality? Are there clear policies for how extensions are managed? I will be surprised if ISMS output meets extensibility goals and could not be extended to support firewall and nat traversal. I would certainly require an explanation from the working group of why this was the case. Sam Hartman Area Director _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms--- End Message ---
_______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
- Summary of ISMS chartering discussion Sam Hartman