[Hubmib] SLC Hubmib Minutes

"Romascanu, Dan (Dan)" <dromasca@avaya.com> Sat, 12 January 2002 07:46 UTC

Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18001 for <hubmib-archive@odin.ietf.org>; Sat, 12 Jan 2002 02:46:08 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA10482; Sat, 12 Jan 2002 02:45:35 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA10451 for <hubmib@optimus.ietf.org>; Sat, 12 Jan 2002 02:45:33 -0500 (EST)
Received: from ierw.net.avaya.com (ierw.net.avaya.com [198.152.13.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17985; Sat, 12 Jan 2002 02:45:29 -0500 (EST)
Received: from ierw.net.avaya.com (localhost [127.0.0.1]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id CAA19028; Sat, 12 Jan 2002 02:44:08 -0500 (EST)
Received: from IS0004AVEXU1.global.avaya.com (h149-49-38-91.avaya.com [149.49.38.91]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id CAA19017; Sat, 12 Jan 2002 02:44:06 -0500 (EST)
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C19B3C.FE98AC7A"
Date: Sat, 12 Jan 2002 09:44:41 +0200
Message-ID: <AAB4B3D3CF0F454F98272CBE187FDE2FF54049@IS0004AVEXU1.global.avaya.com>
Thread-Topic: SLC Hubmib Minutes
Thread-Index: AcGbPReoKt1KKBdfSlWULMmAV+FHIA==
From: "Romascanu, Dan (Dan)" <dromasca@avaya.com>
To: minutes@ietf.org
Cc: hubmib@ietf.org
Subject: [Hubmib] SLC Hubmib Minutes
Sender: hubmib-admin@ietf.org
Errors-To: hubmib-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: <hubmib.ietf.org>
X-BeenThere: hubmib@ietf.org

Please find attached the minutes of the SLC hubmib meeting. 
Regards,
Dan
HUBMIB WG IETF 52, Salt Lake City
Monday afternoon session II
Notes
K.C. - Minutes taker
Dan Romascanu discussion leader
The agenda from the main agenda link is invalid. IETF isn't concerned.
The real hubmib agenda can be found at:
<http://www.ietf.org/ietf/01dec/hubmib.txt>
*	IEEE 802.3 Status Report 
*	two IEEE meetings since London 
*	802.ae 
*	draft 34 in ballot between 11/17 and 12/3 
*	Sponsor Ballot to follow 
*	Standard expected 3/02 and 6/02
*	802.3af 
*	D3.0 in Ballot between 11/16 & 12/30 
*	Standard expected between 9/02 and 11/02 
*	Standard slightly behind time 
*	Changes expected
*	802.3ah (Ethernet first mile) 
*	WG formed - 9/01 
*	Four tracks: 
*	· Fiber p2p 
*	· Copper p2p 
*	· Fiber p2mp 
*	· OAM 
*	Far from IETF involved still too early in IEEE
*	RFC’s 
*	1515 - should be obsolete by 2668 - was not. 
*	2108 
*	2665 
*	2666 
*	2668 
*	Confusion is there due to duplication of rfc’s. 
*	Next rfc on MAU mib will obsolete 1515 and 2668 
*	Need implementation reports. 
*	Enterasys wanted some issues answered before they implement
implementation 
*	reports. 
*	Would be nice to get implementation reports of where 
*	John Flick - Problems with hardware help decide that
non-essential items will not be discussed.
		· Etherlike MIBS
				o What do we do with the test oids now
that the table is gone? - Deprecate?
				o What about multiple manager stations? 
				o rfc1229 Interfaces extensions
mib->rfc1273->deprecated for no implementations. We now have test oids
not in use. Recommended to deprecate and start a loopback test object.
Will post new object to mailing list.
				o Is the IFMTU clear. Someone requested
clarification to this, but it seems clear. It was decided that the
person who doesn’t understand it to give example. It was decided to
leave as is until the person can produce the info.
				o IfAdminStatus (down) needs to be
clarified Mike Mcfadden brought up the issue in the bridge wg where
multiple vendors have multiple reactions to this. Fiber was not tested.
There needs to be clarification needed from IEEE. John will write text
to ask and Dan will make the request.
				o issue on rfc1643 - 2 current versions
of the Ethernet mib. - do we move it to historic, full standard? Should
we put in our current draft an explanation of why there are 2 drafts.
Some vendors are using rfc1643 with private mibs.
		· MAU MIB
				o Some outstanding edits are still here.
There are some issues in the WIS MIB and SONET that will affect some
text.
				o Some issues from the InterWorking labs
test summit may affect this. We will have to wait until at least the end
of January to get its information. Do we wait? 
				o Issues that could come up are
misunderstanding in the implementation? Some packets and octets that
could have misunderstanding. It was decided to wait for the test summit.
				o Some SONET entry in the ifStackEntry
stackables issues. This goes along with the WIS MIB work. Where do we do
the clarification? Decided we would discuss this in the WIS mib meeting.
				o discussed the implementation of the
auto-negotiation duplex info. Some are implementing the MAU mib as is.
Others are implementing this in the private mibs due to being
cumbersome. GBIC swap may only be partly relevant to the configuration.
Use a enumerated integer for setting? This is what some people are
doing. John had posted to the wg how HP is doing their proprietary mib
as a suggestion.
				o Forcing the autonegotiation down
configuration came up. Once again, not having implementation reports to
review against doesn’t help solve the issue. We need more implementation
reports. There are some vendors that have implemented the way as
written.
				o Dan proposed that we do the updates to
the mib as posted previously by John as recommendation of the committee
and let people see it. Mike H. suggested some new oid’s written to help
out with this. People could help by reviewing the jack type enumeration.

				o Power MIB
				o latest draft published November 2001
				o Misc spelling and compile warning
errors were noted.
				o Changes resulting from
IEEEportPortPowerPairs object deleted.
				o Delete off option of the power port
detection control object
				o add new objects to
powerdetectionstatus object.
				o delete powerportclassificationobject
				o update naming of objects
				o Reviewed some implementation notes
from PowerDsine that will be added to next version.
				o The IETF document status is stable. We
don’t know what the IEEE is going to do. For this reason just respin the
draft and wait for the IEEE to go on.
				o Last-call may happen in Feb 02
depending on the IEEE.
The goal is to finish all for the IETF in Minneapolis. in March.
Goals and Milestones
Dec 01 - Gather implementation experience
Jan 02 - Issue revised drafts - Missed
Jan 02 - Forward drafts to AD/IESG - pushed to Feb.
Feb 02 - Last call in Feb.