[GSMP] Draft GSMP minutes

"Kenneth Sundell" <ksundell@nortelnetworks.com> Fri, 14 December 2001 08:49 UTC

Received: from optimus.ietf.org (ietf.org [] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27057 for <gsmp-archive@odin.ietf.org>; Fri, 14 Dec 2001 03:49:33 -0500 (EST)
Received: from optimus.ietf.org (localhost []) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA22226; Fri, 14 Dec 2001 03:44:48 -0500 (EST)
Received: from ietf.org (odin []) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA22197 for <gsmp@ns.ietf.org>; Fri, 14 Dec 2001 03:44:46 -0500 (EST)
Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com []) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27017 for <gsmp@ietf.org>; Fri, 14 Dec 2001 03:44:43 -0500 (EST)
Received: from znsgs01r.europe.nortel.com (znsgs01r.europe.nortel.com []) by zcars0m9.nortelnetworks.com (8.11.0/8.11.0) with ESMTP id fBE8hPF00618 for <gsmp@ietf.org>; Fri, 14 Dec 2001 03:43:25 -0500 (EST)
Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com []) by znsgs01r.europe.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id fBE8hvv26969 for <gsmp@ietf.org>; Fri, 14 Dec 2001 08:43:58 GMT
Received: from zvb1c002.europe.nortel.com (zvbnc0jb.europe.nortel.com []) by zwcwc012.europe.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id YYM8XHBB; Fri, 14 Dec 2001 08:43:33 -0000
Received: from europem01.nt.com (archt6me.us.nortel.com []) by zvb1c002.europe.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id YLNX4N7P; Fri, 14 Dec 2001 09:42:50 +0100
Message-ID: <3C19BD05.1010402@europem01.nt.com>
Date: Fri, 14 Dec 2001 09:49:09 +0100
X-Sybari-Space: 00000000 00000000 00000000
From: Kenneth Sundell <ksundell@nortelnetworks.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2
X-Accept-Language: en-us
MIME-Version: 1.0
To: gsmp@ietf.org
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [GSMP] Draft GSMP minutes
Reply-To: gsmp@ietf.org
Sender: gsmp-admin@ietf.org
Errors-To: gsmp-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: General Switch Management Protocol <gsmp.ietf.org>
X-BeenThere: gsmp@ietf.org
Content-Transfer-Encoding: 7bit

attached is the draft minutes from the last gsmp meeting in salt lake city.
please read the minutes and comment.



Minutes GSMP WG 52nd IETF, Salt Lake City December 2001

Chairs: Avri Doria <avri@apocalypse.com>
       Kenneth Sundell <ksundell@nortelnetworks.com>

Note taker: Kenneth

The meeting was chaired by Avri. The meeting was divided
into three parts; Status report of the documents in IESG
review/IETF last call; Status report from the design teams
and update of the milestone dates.

Documents in IETF Last call or under IESG review

The meeting started with a status report of the documents
on the IESG's desk.

draft-ietf-gsmp-10 got one issue
draft-ietf-gsmp-encaps-04 (three issues)
draft-ietf-gsmp-applicability-03 (no issue)

Kenneth went through the gsmp spec issue and how it was
resolved. There were no comments on the proposed change
that was editorial. The Area Director present also thought
that the solution was reasonable.

Avri presented the three issues with the encaps draft and
proposed changes at the same time. One of the issue raised
by the IESG was about the 2-byte type field indicating the
type code for GSMP messages. The question was if there will
be any other type in the future. The answer was no, since
this field is used for demarkation of individual messages
in TCP stream , it is not expected to be any other.
It was ok'ed by the Area Dirctor.

The second and the third issue concerned how security was
addressed in the encaps draft. Issue #2 pointed at chapter 4.2,
where the security recommendations were regarded as weak.
The spec has been updated with MUST AH and MUST ESP.
There was a comment at the end of the meeting that MUST AH
might be a problem, since it might not be used in most cases.
The AD agreed to this so the AH recommendation was removed.
The AD present also suggested that the word secrecy should be
replaced with "integrity and confidentiality". That change was
made online. The text was changed to the following:

"When GSMPv3 is implemented for use in IP networks, provisions for
security between the controller and client MUST be available and
MUST be provided by IP Security [IPSEC]. In this case,the IPSEC
Encapsulation Security Payload (ESP) MUST be used to provide both
integrity and confidentiality"

And the third issue about security for ATM and Ethernet was
resolved by the following text (chapter 5): 
"The security of GSMP's TCP/IP control channel has been addressed
in Section 4.2. For all uses of GSMP over an IP network it is
REQUIRED that GSMP be run over TCP/IP using the security
considerations discussed in Section 4.2. Security using ATM and
Ethernet encapsulations MAY be provided at the link layer.
Discussion of these methods is beyond the scope of this
specification. For secure operation over any media, the
IP encapsulation with IPsec SHOULD be used."

The AD advised the chairs to advertise the text change
simultaneous with getting the next draft out. During this time,
comments could be invited from the list.  If no substantive
comments on sections 4.2 and 5 were received during a two period
then the document could go back to the IESG for approval without
need for another last call.

The GSMP MIB is in IETF last call which expires December 24th.
The IESG has reviewed the MIB and there have also been SNMP
specialists involved, so it is expected that the MIB is in a
good shape.

Status Report From the Design teams

There are three GSMP design teams working on tasks beyond the base
documents. The Optical Requirement design team has not progressed
much. The idea is to reconstitute the design team. They should take
on the draft-ietf-gsmp-reqs-00 document and enhance it with new
thoughts. Volunteers to join the team are welcome, please send an
email to either of the co-chairs. The work should be done by the
Minneapolis meeting in march 02.

Jonathan Sadler presented the design teams efforts so far.

<Text to be provided by Jonathan Sadler>

The Dynamic Partition team is almost there. Avri presented some
proposed updates to the requirements document. The first issue was
about terminology, she proposed a change from Network Element (NE)
to Physical Device (PD) in order to avoid confusion with the
terminology at the forces wg. The change was accepted. The other
proposal was to change the one-to-one cardinality to one-to-many
in order to allow for multiple controllers per partition.
There was a comment from the author that this was done for
simplicity and that the scheme was describing logical relationships.
Avri and the author agreed that this could be interpreted in two
different ways, so the agreed that a clarification was needed.
The next steps for this documents is to proceed to working group
last call since the document is done. And if accepted, submit to the
IESG with a charter request.

Milestone Discussion and Update

The last part of the meeting was to discuss the milestones
in the charter. Proposed new dates were:

- Document requirements for control of switches supporting optical,
 TDM and other CCAMP features: May 01 -> March 02

- Submit GSMPv3 extensions to include control of switches supporting
 optical, TDM and other CCAMP features and any updates of the base
 spec for Proposed Standard: Aug 01->Sept 02

- Document requirements for switch partitioning and determine whether
 to recharter to extend GSMP capabilities to meet these:
 Sept 01-> Done?

- If requirements process has convinced ADs/IESG, produce GSMP
 extensions and MIBs to support dynamic switch partitioning:
 Dec 01->March/June 02

- Submit GSMPv3, its extensions and MIBs for Draft Standard:
 June 02->Dec 02

The meeting was adjourned by Avri

GSMP mailing list