[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