[TICTOC] Benoit Claise's Discuss on draft-ietf-tictoc-ptp-mib-08: (with DISCUSS)

["Benoit Claise" <[e-mail]>]

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.