| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Hi Geoff, I would like to address the point that you brought up about backward compatibility in your email a couple of days ago. As part of that I would also like to address the comment that you submitted on the final Working Group recirculation ballot of IEEE P802.3bc. While we didn't directly address the comment due to process we did talk about it on the call and I expect that it will be submitted again during the initial Sponsor ballot which is taking place at the moment. For that reason I would like to address where I think we are with it in preparation for the meeting next Wednesday afternoon. Best regards, David Comment on reference to IETF RFC 4836 ===================================== The comment you submitted reads: 'The reference for the numerical value of MauType is not appropriate for our standard in that an obsolete reference is used. All the worse, that reference is actually derived from date in the 802.3 standard. (I have not examined the rest of the draft but I assume that this is a problem throughout the draft.) Use of an external reference for identification of something that we provide a reference to in our own standard will be endlessly confusing.' and the Suggested Remedy you submitted reads 'Replace the external reference with a reference to the equivalent defining value within 802.3. Those values would be currently found in Annex 30B on pages 733-735.'. I would summarize the comment as saying we shouldn't be referencing the dot3MauType enumeration from IETF RFC 4836 in the aLldpXdot3LocPortOperMauType attribute - but instead use an internal reference to the TypeValue enumeration from annex 30B.2. Now when we discussed this we found that despite what the intentions where in the past - these two sets of enumerations do not match - in fact in some cases the same values has a different meaning - as an example the value (14) means 100BASE-T4 for IETF RFC 4836 (though it reference to IANA-MAU-MIB) but 10BASE-T for Annex 30B.2. This I believe means that the suggest remedy can't be implemented as it would not maintain backward compatibility. Based on this I believe that the next suggestion was to aligned IETF RFC 4836 and Annex 30B.2 but since the aLldpXdot3LocPortOperMauType attribute reflects the contents of the TLV, to move away from the dot3MauType enumeration from IETF RFC 4836 would require a new TLV. Hence I suggested to at some point deprecate the current Annex 30B.2 enumerations and align the Annex 30B.2 enumerations to match the current IETF RFC 4836 enumerations - then augment them as required. I've been thinking about this further, particularly from the point of view of when we add a new PHY to IEEE Std 802.3. Now IETF RFC 4836 actually references the IANA-MAU-MIB for the dot3MauType enumeration and the process to add a new enumerations is described as follows: 'It is intended that each new MAU type, Media Availability state, Auto Negotiation capability and/or Jack type defined by the IEEE 802.3 working group and approved for publication in a revision of IEEE Std 802.3 will be added to this MIB module, provided that it is suitable for being managed by the base objects in the MAU-MIB. An Expert Review, as defined in RFC 2434 [RFC2434], is REQUIRED for such additions.' RFC 2434 describes an 'Expert Review' as 'approval by a Designated Expert is required'. The point to me however is that there seems to be a low overhead method already defined to add dot3MauType enumerations to be carried in the TLV in support of new PHYs we defined. Even if we were to align Annex 30B.2 to match what is currently in IANA-MAU-MIB the rate at which IANA-MAU-MIB can be changed is much faster that we can modify Annex 30B.2. If we were to move to use Annex 30B.2 enumerations for the TLV the only way we could add a new enumeration for a new PHY is to modify 30B.2 as part an IEEE 802.3 project. I would also observe that once Annex 30A and 30B are moved to IEEE 802.3.1, which is within the current stated scope and purpose of IEEE P802.3.1 - we may well have the situation where two PARs would be required to complete a project to add a new PHY - a IEEE 802.3 project for the PHY - and a IEEE 802.3.1 project to add the enumeration to support the new PHYType in the TLV. My fundamental point is that what we have in IEEE Std 802.1AB-2005 today - and what we have in the IEEE P802.3bc draft is not broken - and provides a reasonable method to add new enumerations for new PHY types enumerations - as well as other enumerations used in the TLVs. Need for Annex 30B ================== I believe that this topic came up when we were discussing where the specification for things like 'INTEGER', 'BOOLEAN' and 'SEQUENCE OF' found in Clause 30 are to be found. Subclause 30.1.4 'Management model' states that 'Managed objects are defined in terms of four types of elements:' and we list attributes, actions, notifications and behaviours. It then states that 'The above items are defined in 30.3 through 30.3.7 of this clause in terms of the template requirements of ISO/IEC 10165-4: 1991.'. Looking at ISO/IEC 10165-4: 1991 'Information technology -- Open Systems Interconnection -- Structure of management information -- Part 4: Guidelines for the definition of managed objects', under the Attribute template, in subclause 8.7.3.2 'WITH ATTRIBUTE SYNTAX type-reference' it states that 'This construct, present only if the DERIVED FROM construct is absent, identifies the ASN.1 data type that describes how instances of this attribute are carried in protocol' and sure enough ASN.1 defined in ISO/IEC 8824 defines 'INTEGER', 'BOOLEAN' and 'SEQUENCE OF'. I further note that there is no mention of Annex 30B in Clause 30. Based on this I still believe that Clause 30 is indeed a complete protocol-independent management definition. IEEE P802.3bc aLldpXdot3PortConfigTLVsTxEnable ---------------------------------------------- In respect to the subclause 30.12.1.1.1 aLldpXdot3PortConfigTLVsTxEnable found in IEEE P802.3bc, based on the above, I do not see the definition as incomplete. I did however do a review of the IEEE P802.3bc Clause 30 attributes against the equivalent IEEE Std 802.1AB SMIv2 objects - see attached pdf file [ IEEE_P802d3bc_CLS30_d1AB.pdf ] - and while I think the SEQUENCE syntax would work if it were a SEQUENCE OF BOOLEAN I think a syntax of BITS would be a better match. I do agree however that while the use of maxFrameSize is local to the MIB, it is indeed a bad idea to use it as it is used elsewhere to mean something else. Based on this I've submitted two comment against the sponsor ballot.
Attachment:
IEEE_P802d3bc_CLS30_d1AB.pdf
Description: Binary data