[Hubmib] RFC 5066 Comment on PME initialization and aggregation
"Baud, Yann" <yann.baud@schmid-telecom.ch> Thu, 18 November 2010 11:04 UTC
Return-Path: <yann.baud@schmid-telecom.ch>
X-Original-To: hubmib@core3.amsl.com
Delivered-To: hubmib@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF7AB3A6813 for <hubmib@core3.amsl.com>; Thu, 18 Nov 2010 03:04:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.441
X-Spam-Level:
X-Spam-Status: No, score=0.441 tagged_above=-999 required=5 tests=[AWL=1.550, BAYES_05=-1.11, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hF8y1YuFwzgC for <hubmib@core3.amsl.com>; Thu, 18 Nov 2010 03:04:25 -0800 (PST)
Received: from mail.schmid-telecom.ch (mail.schmid-telecom.ch [213.173.183.22]) by core3.amsl.com (Postfix) with ESMTP id 710263A681D for <hubmib@ietf.org>; Thu, 18 Nov 2010 03:04:24 -0800 (PST)
Received: from szexchange.schmid-telecom.com [10.100.100.66] by mail.schmid-telecom.ch with XWall v3.40 ; Thu, 18 Nov 2010 12:05:10 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB8710.779F471B"
Date: Thu, 18 Nov 2010 12:05:09 +0100
Message-ID: <14D81EC6B257AC4AA681E4969BCC58BE01B8F05D@szexchange.schmid-telecom.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Hubmib] RFC 5066 Comment on PME initialization and aggregation
Thread-Index: AcuHEHcXNLG6FwzvT1O4to4XqANPOw==
From: "Baud, Yann" <yann.baud@schmid-telecom.ch>
To: hubmib@ietf.org
Subject: [Hubmib] RFC 5066 Comment on PME initialization and aggregation
X-BeenThere: hubmib@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Ethernet Interfaces an Hub MIB WG <hubmib.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/hubmib>, <mailto:hubmib-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/hubmib>
List-Post: <mailto:hubmib@ietf.org>
List-Help: <mailto:hubmib-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hubmib>, <mailto:hubmib-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Nov 2010 11:06:02 -0000
I wish to comment on the penultimate paragraph of RFC 5066 section 3.1.3: *Quoted* Note that the PCS port does not have to be operationally 'down' for the connection to succeed. In fact, a dynamic PME addition (and removal) MAY be implemented with an available PME being initialized first (by setting its ifAdminStatus to 'up') and then added to an operationally 'up' PCS port, by modifying a respective ifStackTable (and respective ifInvStackTable) entry. In fact, PME addition to a PCS is impossible once the PME has been initialized, because the discovery and aggregation phases, which are done using ITU-T G.994.1 (G.Hs), must occur before PME training and activation in the PME initialization process. Once the PME is initialized, it is impossible to configure the aggregation on the peer pme (IEEE 802.3 2008 61.4.7). I would much welcome a clarification on this paragraph. Best Regards, Yann