[TICTOC] Benoit Claise's Discuss on draft-ietf-tictoc-ptp-mib-08: (with DISCUSS)
"Benoit Claise" <bclaise@cisco.com> Wed, 20 April 2016 12:04 UTC
Return-Path: <bclaise@cisco.com>
X-Original-To: tictoc@ietf.org
Delivered-To: tictoc@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BA3112D130; Wed, 20 Apr 2016 05:04:34 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Benoit Claise <bclaise@cisco.com>
To: The IESG <iesg@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 6.19.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20160420120434.32329.12375.idtracker@ietfa.amsl.com>
Date: Wed, 20 Apr 2016 05:04:34 -0700
Archived-At: <http://mailarchive.ietf.org/arch/msg/tictoc/Fn-K134Z3mIqwJdYoWw5jlnjKhk>
Cc: draft-ietf-tictoc-ptp-mib@ietf.org, dromasca@avaya.com, tictoc-chairs@ietf.org, tictoc@ietf.org, kodonog@pobox.com, rick.casarez@gmail.com
Subject: [TICTOC] Benoit Claise's Discuss on draft-ietf-tictoc-ptp-mib-08: (with DISCUSS)
X-BeenThere: tictoc@ietf.org
X-Mailman-Version: 2.1.17
List-Id: Timing over IP Connection and Transfer of Clock BOF <tictoc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tictoc>, <mailto:tictoc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tictoc/>
List-Post: <mailto:tictoc@ietf.org>
List-Help: <mailto:tictoc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tictoc>, <mailto:tictoc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Apr 2016 12:04:34 -0000
Benoit Claise has entered the following ballot position for draft-ietf-tictoc-ptp-mib-08: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tictoc-ptp-mib/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- As stressed by Dan Romascanu part of his MIB doctor review, clearly not ready to go This is the MIB Doctor Review for draft-ietf-tictoc-ptp-mib-08.txt. Note that this document has a long history. A MIB Doctor review was performed already by Bert Wijnen back in 2011. I do not believe that this document is ready for approval in its current form. Here are my findings. 1. PARSING Using smilint: smistrip -d mibs docs/draft-ietf-tictoc-ptp-mib-08.txt timeout 10 smilint -s -e -l 5 mibs/PTPBASE-MIB 2>report.txt You can access any intermediately created files, the processing report (which might be empty if no errors or warnings have been found), and output files (in case of a conversion request) for reading and download from a temporary server directory for approx. 24 hours. While processing your request the following errors and/or warnings have been found: mibs/PTPBASE-MIB:426: [2] {bad-identifier-case} `XXX' should start with a lower case letter mibs/PTPBASE-MIB:426: [2] {object-identifier-not-prefix} Object identifier element `XXX' name only allowed as first element mibs/PTPBASE-MIB:26: [2] {module-identity-registration} illegal module identity registration Using smicng (thanks to Bert Wijnen): C:\bw\smicng\work>smicng ptpbase.inc Successful parsing C:\bw\smicng\work> **** now setup for STRICT checking: C:\bw\smicng\work>smicstrict C:\bw\smicng\work>smicng ptpbase.inc W: f(rfc2863.mi2), (274,17) Item "ifPhysAddress" should have SIZE specified E: f(rfc2863.mi2), (1092,23) Index item "ifRcvAddressAddress" must be defined with syntax that includes a SIZE W: f(rfc2863.mi2), (1084,1) Row "ifRcvAddressEntry" has indexing that may create variables with more than 128 sub-ids W: f(rfc2863.mi2), (1103,17) Item "ifRcvAddressAddress" should have SIZE specified W: f(rfc2863.mi2), (1146,15) Variable "ifIndex" in notification "linkDown" is an index for a table W: f(rfc2863.mi2), (1158,15) Variable "ifIndex" in notification "linkUp" is an index for a table W: f(rfc2863.mi2), (1691,1) OBJECT-GROUP "ifOldObjectsGroup" is not used in a MODULE-COMPLIANCE in current module E: f(ptpbase.mi2), (413,19) Sub-Id for item "ptpbaseMIB" must be "number" or "name(number)" format *** 2 errors and 6 warnings in parsing C:\bw\smicng\work> As the two errors refer to the RFC 2863 module rather than to the PTBASE-MIB: the compilation seems clean. 2. TEXTUAL CONVENTIONS are prefixed differently than the MIB objects. This is not forbidden, but it creates inconsistency. Also the prefix ‘Clock’ for the TCs hints to a more generic functionality, although the TCs seem to be PTP-related. I would suggest prefixing the TCs also with PTP or Ptp 3. The following TC ClockIdentity ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The clock Identity is an 8-octet array... REFERENCE "Section 7.5.2.2.1 from [IEEE SYNTAX OCTET STRING (SIZE (1..255)) If this is 8-Octet why is the OCTET STRING size 255? 4. I see in the Abstract: This memo specifies a MIB module in a manner that is both compliant to the SNMPv2 SMI, and semantically identical to the peer SNMPv1 definitions. Do you actually mean SMIv2 rather than SNMPv2 SMI? I am not sure why this is important, but if this is important, please provide a reference to the document that includes the ‘peer SNMPv1’ definitions (probably SMIv1) 5. Most of the document speaks about PTP, but in the DESCRIPTION clause at page 7 it mentions: [IEEE 1588-2008] defines a protocol enabling precise synchronization of clocks in measurement and control systems implemented with packet-based networks, the Precision Time Protocol Version 2 (PTPv2). This MIB does not address the earlier version IEEE Std. 1588(TM)-2002 (PTPv1). So, when it says ‘PTP’ does it mean PTPv2 or any version of PTP? It would be good to clarify. 6. The document uses the improper terminology ‘MIB’ when it means MIB module. For example ‘Relationship to other Profiles and MIBs’ or ‘This MIB is intended to be used …’ etc., etc., 7. Idnits complains about an obsolete reference to RFC 1906: -- Obsolete informational reference (is this intentional?): RFC 1906 (Obsoleted by RFC 3417) 8. I do not believe that Section 3 includes any useful information. 9. The DESCRIPTION clause is unusually long and includes a lot of abbreviations, terminology, architectural details and other pieces of information which is not clear why they need to be hardcoded in the MIB module. Maybe the place for all these is in the currently empty-content section 3? 10. I do not understand how the ClockPortTransportTypeAddress TC works. If this TC defines an address type why is it not an enumeration? What is the string that for example indicates IPv6? Is it ‘IPv6’? who guarantees that a manager and an agent spell the same? Or is the intention to use the list of identifiers for ‘Well Known transport types for PTP communication’at page 64? If yes, how is this extended? Probably an IANA maintained enumerated TC would be a better solution. 11. Why is not the SYNTAX of ClockQualityClassType an enumeration, when the DESCRIPTION indicates clearly that this is an enumeration. 12. I do not understand how ClockTimeInterval works. The example does not help either. It says ‘For example, 2.5 ns is expressed as 0000 0000 0002 8000 in Base16.’ and than the SYNTAX is SYNTAX OCTET STRING (SIZE (1..255)) What is the STRING for the object in this example? 13. For objects like ptpDomainIndex there is no need to copy again the possible values in the DESCRIPTION clause, because these are already listed in the TC. 14. Why is ptpDomainClockPortsTotal of SYNTAX Gauge32? Does this value change all the time? Does it latch at a max value? 15. There is no indication of behavior for counter discontinuity, or object for counter discontinuity – see section 4.6.1.2 in RFC 4181 16. Why is the SYNATX of ptpbaseClockTransDefaultDSNumOfPorts Counter32? This does not seem to be a counter, but an unsigned integer. 17. The DESCRIPTION clause of the ptpbaseClockPortDSPTPVersion objects reads: "This object specifies the PTP version being used.” However, the DESCRIPTION clause of the MIB module says that this module refers only to PTPv2. So what does this object stand for? And in any case, how is this coded? (1) for v1 and (2) for v2? Then why is it not an enumerated value? 18. How does ptpbaseClockPortAssociateAddressType work? What would be included under the AutonomousType SYNTAX to make possible interoperability? 19. The Security Considerations section does not follow the template defined at http://trac.tools.ietf.org/area/ops/trac/wiki/mib-security.
- [TICTOC] Benoit Claise's Discuss on draft-ietf-ti… Benoit Claise