|Thread Links||Date Links|
|Thread Prev||Thread Next||Thread Index||Date Prev||Date Next||Date Index|
Good point. We met it again : )
It is similar to the discussion we had on PSE module in Nov. meeting, since Std 802.3.1 MIB provides extra objects/attributes which are not in CL 30.
The statement was CL 30 provides objects/attributes that management system can access to for managing IEEE 802.3 devices. Besides, attributes derived from CL45 can also be used by management system.
So when managing 802.3 devices, we can use these *access* provided by IEEE 802.3. Otherwise, we cannot make sure if the managed devices provide accesses for some managements.
For this sort of discussions, the question should be whether we can have these attributes/objects in 802.3 YANG modules if they are not in CL30/45.
In general, there are cases:
1. Objects/attributes defined in Std 802.3.1
Thanks for Geoff’s background. If CL 30 was assumed to define basic measurements while Std 802.3.1 is more functionality for management, which is a standardized implementation for SNMP management of Ethernet. I think that should not be a problem, YANG modules can also refer to objects/attributes from Std 802.3.1.
2. Objects/attributes defined in IETF RFCs and elsewhere
We will have to achieve consensus to include these attributes into 802.3 modules.
One suggestion is that we can have the modules with set of attributes/objects from CL30/45 and 1) as basis first and include new attributes from 2) with consensus through discussions.
Ps: and yes, we would aim to provide same level of functionality as Std 802.3.1 does.
Cl. 30was never intended to be a full Mgmt standard
nor was it intended to be specific to any protocol.
802.3.1 was intended to fully specify a standardized implementation of SNMP management of Ethernet.
My understanding was that the YANG project intended to be equivalent in functionality to 802.3.1.