Skip to main content

Definitions of Managed Objects for Network Time Protocol Version 4 (NTPv4)
RFC 5907

Revision differences

Document history

Date Rev. By Action
2015-10-14
07 (System) Notify list changed from ntp-chairs@ietf.org, draft-ietf-ntp-ntpv4-mib@ietf.org to (None)
2012-08-22
07 (System) post-migration administrative database adjustment to the No Objection position for Cullen Jennings
2012-08-22
07 (System) post-migration administrative database adjustment to the No Objection position for Tim Polk
2012-08-22
07 (System) post-migration administrative database adjustment to the No Objection position for Adrian Farrel
2012-08-22
07 (System) post-migration administrative database adjustment to the No Objection position for Russ Housley
2010-06-21
07 Cindy Morgan State Changes to RFC Published from RFC Ed Queue by Cindy Morgan
2010-06-21
07 Cindy Morgan [Note]: 'RFC 5907' added by Cindy Morgan
2010-06-21
07 (System) RFC published
2010-04-02
07 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2010-04-01
07 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2010-04-01
07 (System) IANA Action state changed to In Progress from Waiting on Authors
2010-03-15
07 Cindy Morgan State Changes to RFC Ed Queue from Approved-announcement sent by Cindy Morgan
2010-03-15
07 (System) IANA Action state changed to Waiting on Authors from In Progress
2010-03-15
07 (System) IANA Action state changed to In Progress
2010-03-15
07 Amy Vezza IESG state changed to Approved-announcement sent
2010-03-15
07 Amy Vezza IESG has approved the document
2010-03-15
07 Amy Vezza Closed "Approve" ballot
2010-03-15
07 Amy Vezza State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Amy Vezza
2010-03-15
07 Ralph Droms [Ballot Position Update] New position, Yes, has been recorded by Ralph Droms
2010-03-12
07 Adrian Farrel [Ballot Position Update] Position for Adrian Farrel has been changed to No Objection from Discuss by Adrian Farrel
2010-03-08
07 Russ Housley [Ballot Position Update] Position for Russ Housley has been changed to No Objection from Discuss by Russ Housley
2010-03-05
07 (System) New version available: draft-ietf-ntp-ntpv4-mib-07.txt
2010-02-25
07 Tim Polk [Ballot Position Update] Position for Tim Polk has been changed to No Objection from Undefined by Tim Polk
2010-02-25
07 Tim Polk [Ballot Position Update] Position for Tim Polk has been changed to Undefined from Discuss by Tim Polk
2010-02-11
07 Dan Romascanu
[Ballot comment]
1. Most DisplayString objects have been changed into Utf8String objects, but there are still a few objects where they use DisplayString.I understand that …
[Ballot comment]
1. Most DisplayString objects have been changed into Utf8String objects, but there are still a few objects where they use DisplayString.I understand that in these cases there will (most probably) never be international text, so we can live with this. On the other hand, I do not see what the problem would be to also make those utf8 based. If the content is ASCII, then basically that is exactly the same, no matter if it is repreented in UTF8 or ASCII.

2. Now that they use Utf8String (from RFC 2287), I think that RFC2287 should be added as a normative reference.

3. It would be nice to acknowledge the contribution of the MIB Doctor Bert Wijnen.
2010-02-11
07 Dan Romascanu
[Ballot comment]
1. Most DisplayString objects have been changed into Utf8String objects, but there are still a few objects where they use DisplayString.I understand that …
[Ballot comment]
1. Most DisplayString objects have been changed into Utf8String objects, but there are still a few objects where they use DisplayString.I understand that in these cases there will (most probably) never be international text, so we can live with this. On the other hand, I do not see what the problem would be to also make those utf8 based. If the content is ASCII, then basically that is exactly the same, no matter if it is repreented in UTF8 or ASCII.

2. Now that they use Utf8String (from RFC 2287), I think that RFC2287 should be added as a normative reference.
2010-02-11
07 Dan Romascanu [Ballot discuss]
2010-02-11
07 Dan Romascanu [Ballot Position Update] Position for Dan Romascanu has been changed to No Objection from Discuss by Dan Romascanu
2010-01-22
07 Cullen Jennings [Ballot Position Update] Position for Cullen Jennings has been changed to No Objection from Discuss by Cullen Jennings
2009-12-02
07 Russ Housley [Ballot comment]
2009-12-02
07 Russ Housley [Ballot discuss]
The following comment was raised by Ben Campbell in his Gen-ART
  Review:

  RFC 2119 language introduced without the normal boilerplate.
2009-10-24
07 Adrian Farrel [Ballot comment]
Thanks, looks like you took care of all my Comments.
2009-10-24
07 Adrian Farrel
[Ballot discuss]
Thank you for addressing the bulk of my Discuss issues.

One remains. Maybe you want to discuss this in email?

Discuss 4

In …
[Ballot discuss]
Thank you for addressing the bulk of my Discuss issues.

One remains. Maybe you want to discuss this in email?

Discuss 4

In general, it seems odd to have DisplayString and Integer variants
of many objects. It causes the implementer to have to handle the case
when the objects do not agree.

In some cases, this is particluarly bad. For example, why is
ntpEntStatusCurrentMode a DisplayString with a well-known set of
legitimate values? Surely this gives rise to potential discrepencies.
Doesn't ntpEntStatusCurrentModeVal give you everything you need?
2009-10-08
07 (System) Sub state has been changed to AD Follow up from New Id Needed
2009-10-08
06 (System) New version available: draft-ietf-ntp-ntpv4-mib-06.txt
2009-04-10
07 Amy Vezza State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation - Defer by Amy Vezza
2009-04-09
07 Lisa Dusseault [Ballot Position Update] New position, No Objection, has been recorded by Lisa Dusseault
2009-04-08
07 Pasi Eronen [Ballot Position Update] New position, No Objection, has been recorded by Pasi Eronen
2009-04-08
07 Magnus Westerlund [Ballot Position Update] New position, No Objection, has been recorded by Magnus Westerlund
2009-04-07
07 Ralph Droms Responsible AD has been changed to Ralph Droms from Mark Townsley
2009-04-07
07 Tim Polk
[Ballot discuss]
As noted, by several others, the guidelines in http://www.ops.ietf.org/mib-security.html
were not used to develop the security considerations section.  I believe there are plausible …
[Ballot discuss]
As noted, by several others, the guidelines in http://www.ops.ietf.org/mib-security.html
were not used to develop the security considerations section.  I believe there are plausible
attacks based on changes to the notification values, and some of the read-only information
may be useful in designing a successful attack (e.g., product name and software version).
(It is less clear to me if the objects in sections 2 and 3, "Current NTP status" and "The status
of all currently mobilized associations" are of utility to an attacker.)

These issues should be documented consistent with the guidelines referenced above.
2009-04-07
07 Tim Polk [Ballot Position Update] New position, Discuss, has been recorded by Tim Polk
2009-04-07
07 Ron Bonica [Ballot comment]
Supporting Dan's discuss
2009-04-07
07 Ron Bonica [Ballot Position Update] New position, No Objection, has been recorded by Ron Bonica
2009-04-07
07 Robert Sparks [Ballot comment]
Support Adrian's and Dan's discusses
2009-04-07
07 Robert Sparks [Ballot Position Update] New position, No Objection, has been recorded by Robert Sparks
2009-04-07
07 Lars Eggert [Ballot Position Update] New position, No Objection, has been recorded by Lars Eggert
2009-04-06
07 Cullen Jennings [Ballot comment]
Support Discuss from several other ADs.
2009-04-06
07 Cullen Jennings [Ballot discuss]
MIB needs the new licenses text.
2009-04-06
07 Cullen Jennings [Ballot Position Update] New position, Discuss, has been recorded by Cullen Jennings
2009-04-05
07 Dan Romascanu
[Ballot discuss]
The DISCUSS below is based in part on the MIB Doctor review performed by Bert Wijnen. This review was sent to the NTP …
[Ballot discuss]
The DISCUSS below is based in part on the MIB Doctor review performed by Bert Wijnen. This review was sent to the NTP WG list, but was never answered and the document was not revised.

1. The MIB module does not compile clean.

SMICng results:

  C:\bw\smicng\work>smicng ntpv4.inc
  E: f(ntpv4.mi2), (272,14) Default value for "ntpEntStatusCurrentModeVal"
      must be a name and not a number

  *** 1 error and 0 warnings in parsing

This means changing
    DEFVAL { 99 }
into
    DEFVAL { unknown }
which will fix it.


2. There are two writable objects for which there is no text in the DESCRIPTION clauses about expected persistency behaviour

3. There are Counter32 objects with no test in the DESCRIPTION clauses about possible discontinuities and which timer object would indicate such.
Specifically, the fact that the ntpd keeps track of the Counters, it seems that there may be discontinuities at other times than when the snmpd restarts (e.g. at other times than reset of sysUpTime)

4. There is a lot of commented text in the MIB module which would rather be included in the DESCRIPTION clauses of the objects (the information that is contained seems usefeul)

5. The design of duplicate MIB objects with similar semantics in both text and numerical formats is broken. I suggest to eliminate ntpEndTimeResolution and ntpEntTimePrecision and rather define UNITS clauses for the numerical objects, or units objects if this is not possible. Similarly I would give ntpEntStatusCurrentMode up and keep just ntpEntStatusCurrentModeVal. The text objects are not too useful, are not interoperable, and they may be derived easily by a management station if needed. Duplication also can lead to inconsistency (what would a manager do if the two values are not consistent?)

6. ntpEntSoftName, ntpEntSoftwareVersion duplicate functionality from the Entity MIB

7. The whole list of REVISION clauses is useless. Normally we only have a
single revision clause at RFC publication time. Not a list of revisions that took place during I-D revisions.

8. The Copyright statement in the DESCRIPTION clause of the MODULE_IDENTITY is missing

9. The statement that this revision of the document is published as RFC xxxx
  (xxxx to be filled in by RFC-editor)
is missing

10. There are severa objects with a SYNTAX of DisplayString. I would like to point out "note 2" on web page
      http://www.ops.ietf.org/mib-common-tcs.html
  Note 2.  DisplayString does not support internationalized text.
            It MUST NOT be used for objects that are required to
            hold internationalized text (which is always the case
            if the object is intended for use by humans [RFC2277]).
            Designers SHOULD consider using SnmpAdminString,
            Utf8String, or LongUtf8String for such objects.


11. Instead of
    ntpEntNotifPrefix  OBJECT IDENTIFIER ::= { ntpSnmpMIBObjects 6 }
    ...
    ntpEntNotifications OBJECT IDENTIFIER ::= { ntpEntNotifPrefix 0 }

  I propose/suggest to do
    ntpEntNotifications OBJECT IDENTIFIER ::= { ntpSnmpMIB 0 }

This makes it more inline with  the current practice in MIB modules. Also makes the OIDs of notifications shorter

12. I strongly recommend to use the MIB structure as per RFC4181, which suggests that you would replace
      ntpEntConformance OBJECT IDENTIFIER ::= { ntpSnmpMIB 6 }
  with
      ntpEntConformance OBJECT IDENTIFIER ::= { ntpSnmpMIB 2 }

13. There are OBJECT-GROUP definitions like
  ntpEntObjectsGroup1 OBJECT-GROUP
      OBJECTS {
              ntpEntSoftwareName,
              ntpEntSoftwareVersion,
              ntpEntSoftwareVersionVal,
              ntpEntSoftwareVendor,
              ntpEntSystemType,
              ntpEntStatusEntityUptime,
              ntpEntStatusDateTime,
              ntpAssocName,
              ntpAssocRefId,

              ntpAssocAddressType,
              ntpAssocAddress
    }
    STATUS      current
    DESCRIPTION
        "A collection of objects for the NTP MIB that all NTP
          or SNTP entities should implement."
    ::= { ntpEntGroups 1 }

Text about "should implement" or "optional" or such is NOT supposed to be
in an OBJECT-GROUP DESCRIPTION clause. The OBJECT-GROUP is only meant to group objects logically together. If such a group is mandatory or optional is something that is expressed via MANDATORY-GROUPS or via the GROUP clauses in the MODULE-COMPLIANCE.

As another example

    ntpEntObjectsGroup2 OBJECT-GROUP
    ...
    DESCRIPTION
        "A collection of objects for the NTP MIB that are optional
        for NTP or SNTP entities to implement."
    ::= { ntpEntGroups 2 }

So here the text says that the group is optional while it listed as a MANDATORY-GROUP here:

    ntpEntNTPCompliance MODULE-COMPLIANCE
      STATUS      current
      DESCRIPTION
          "The compliance statement for SNMP entities which use NTP and
          implement the NTP MIB"
      MODULE  -- this module
          MANDATORY-GROUPS {
                          ntpEntObjectsGroup1,
                          ntpEntObjectsGroup2,
                          ntpEntNotifPrefixGroup
        }
        ::= { ntpEntCompliances 1 }

  So that is a conflict in the MIB-Module.

14. Several references/citations look like:

NtpDateTime ::= TEXTUAL-CONVENTION
    DISPLAY-HINT "4d:4d:4d.4d"
    STATUS      current
    DESCRIPTION
        "NTP date/time on the device, in 128-bit
        NTP date format. Ref: draft-ietf-ntp-ntpv4-proto-06,
        section 6:
          It includes a 64-bit signed seconds field
          spanning 584 billion years and a 64-bit fraction
          field resolving .05 attosecond (i.e. 0.5e-18).
          For convenience in mapping between formats, the
          seconds field is divided into a 32-bit era field
          and a 32-bit timestamp field.

        If time is not syncronized this field shall be a
        zero-length string.

        This TC is not to be used for objects that are used
        to set the time of the node querying this object.

        NTP should be used for this--or at least SNTP."
    SYNTAX      OCTET STRING (SIZE (0 | 16))

I suggest that the pointer to Ref: draft-ietf-ntp-ntpv4-proto-06 is changed to Ref: RFC yyyy (and ask RFC-editor to fill in that yyyy value.  In genreal though, it is better to use the REFERENCE clause. So it would be something like

    REFERENCE  "Network Time Protocol Version 4 Protocol
                                And Algorithms Specification, sect 6, RFC yyyy"

15. It seems to me that for something like this:
  ntpEntStatusEntityUptime OBJECT-TYPE
      SYNTAX      Unsigned32
      MAX-ACCESS  read-only
      STATUS      current
      DESCRIPTION
          "The uptime of the NTP entity in seconds."
      -- time since ntpd was (re-)started (not sysUptime!)
      DEFVAL { 0 }
      ::= { ntpEntStatus 9 }

It's better to use UNITS clauses. 

Same for all Counter32 objects - defining UNITS clauses would be very helpful.

16. DEFVAL does not make sense for read-only objects.

17.
  ntpEntStatPktModeTable OBJECT-TYPE
    SYNTAX          SEQUENCE OF NtpEntStatPktModeEntry
    MAX-ACCESS      not-accessible
    STATUS          current
    DESCRIPTION
        "The number of packets sent and received by packet mode."
    ::= { ntpEntStatus 18 }

  ntpEntStatPktModeEntry OBJECT-TYPE
    SYNTAX      NtpEntStatPktModeEntry
    MAX-ACCESS  not-accessible

    STATUS      current
    DESCRIPTION
        "The number of packets sent and received by packet mode."
    INDEX      { ntpEntStatPktMode }
    ::= { ntpEntStatPktModeTable 1 }

How comes that the same DESCRIPTION clause is defined for each of these?

18.

ntpAssocAddressType OBJECT-TYPE
    SYNTAX      InetAddressType
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION
        "The type of address of the association."
    -- contains the type of address for uni/multi/broadcast associations
    ::= { ntpAssociationEntry 4 }

ntpAssocAddress OBJECT-TYPE
    SYNTAX      InetAddress
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION
        "The IP address (IPv4 or IPv6) of the association."
    -- contains IP address of uni/multi/broadcast associations
    ::= { ntpAssociationEntry 5 }

RFC4001 states that the use of InetAddress SYNTAX, MUST have a DESCRIPTION clause that explains/states which object of SYNTAX InetAddressType controls the format of the InetAddress object. It is most probably ntpAssocAddressType but it would be good to state so.

Besides, if you are sure that this ALWAYS only applies to IPv4 and IPv6, then it is better to do as follows:

    ntpAssocAddressType OBJECT-TYPE
      SYNTAX      InetAddressType { ipv4, ipv6 }

  ntpAssocAddress OBJECT-TYPE
      SYNTAX      InetAddress SIZE(4|16)

You must check if you also want to use Zoned addressed, because then that must be added too.

If, at the other hand, other values than ipv4/ipv6 are possible (maybe  in the future?) then it might be better to put the "minimum support for ipv4/ipv6 requirement in the MODULE-COMPLIANCE via an OBJECT  and SYNTAX clause.

19. There are some 8 notifications. Is there a risk that too many get generated at any point in time, such that it would flood the network and/or overload a NMS ??

It would be good to add some text about the expected max notification rates and/or add a throtle or an enable/disable switch.

20. It seems that RFC4001 is missing as a normative reference.

21. draft-ietf-ntp-ntpv4-proto-11 (version 4 of NTP)should also be a normative reference

22. The security section is not according to the guidelines provided at http://www.ops.ietf.org/mib-security.html
2009-04-05
07 Dan Romascanu [Ballot Position Update] New position, Discuss, has been recorded by Dan Romascanu
2009-04-04
07 Adrian Farrel
[Ballot discuss]
Discuss 1

The document does not state which track this is on.
I can find nothing in the write-up either.

Discuss 2

http://www.ops.ietf.org/mib-security.html …
[Ballot discuss]
Discuss 1

The document does not state which track this is on.
I can find nothing in the write-up either.

Discuss 2

http://www.ops.ietf.org/mib-security.html describes the security text
that should be present. The security section seems particularly light.

Discuss 3
                                                                             
The copyright appears to be missing from within the MIB module.

Discuss 4

In general, it seems odd to have DisplayString and Integer variants
of many objects. It causes the implementer to have to handle the case
when the objects do not agree.

In some cases, this is particluarly bad. For example, why is
ntpEntStatusCurrentMode a DisplayString with a well-known set of
legitimate values? Surely this gives rise to potential discrepencies.
Doesn't ntpEntStatusCurrentModeVal give you everything you need?

Discuss 5

Several read-only objects have DEFVAL clauses. This has no meaning!

Discuss 6

Shouldn't ntpEntStatusEntityUptime use a TimeStamp syntax?
2009-04-04
07 Adrian Farrel [Ballot Position Update] New position, Discuss, has been recorded by Adrian Farrel
2009-04-04
07 Adrian Farrel
[Ballot comment]
Comment 1

The MIB module guidelines say that you should include boilerplate
for RFC 2119. However, there is no such language used …
[Ballot comment]
Comment 1

The MIB module guidelines say that you should include boilerplate
for RFC 2119. However, there is no such language used (which is a
bit surprising) so perhaps the boilerplate is not needed.

Comment 2

It would be nice if the modules included by the IMPORTS clause
were identified by RFC name (in comments) and included as
normative references.

Comment 3

I think the longish change log comment should be removed before
publication as an RFC.

Comment 4

You should update the REVISION clause so that the published RFC
is the first revision of this MIB module.

Comment 5 - Nits

Abstract
s/independant/independent/
s/Internet draft/document/

Comment 6

Instead of stating "Ref: draft-ietf-ntp-ntpv4-proto-06" within
a DESCRIPTION clause, you should include a REFERENCE clause.

It might be good if you included a request to the RFC Editor
so that REFERENCE clauses citing draft-ietf-ntp-ntpv4-proto-06
will be updated to indicate the RFC number of that work which
we assume will go forward in lock-step.
2009-04-04
07 Russ Housley
[Ballot comment]
Ben Campbell got an "unknown address error" for chelliot@cisco.com when
  he sent his Gen-ART Review.  Please make sure all the author addresses …
[Ballot comment]
Ben Campbell got an "unknown address error" for chelliot@cisco.com when
  he sent his Gen-ART Review.  Please make sure all the author addresses
  are correct prior to publication.
2009-04-04
07 Russ Housley
[Ballot discuss]
The following comment was raised by Ben Campbell in his Gen-ART
  Review, and no response has been received.  Please respond to the …
[Ballot discuss]
The following comment was raised by Ben Campbell in his Gen-ART
  Review, and no response has been received.  Please respond to the
  comment.  Ben said:

  The comment says "shows the resolution based on 1 second, e.g. "1ms"
  translates to 1000". That confused me at first, since 1ms != 1000 s.
  I suspect you are talking about the number of divisions in a second, 
  in which 1000 would make sense--but I didn't immediately get that 
  from the text.
2009-04-04
07 Russ Housley [Ballot Position Update] New position, Discuss, has been recorded by Russ Housley
2009-03-28
07 Alexey Melnikov [Ballot Position Update] New position, No Objection, has been recorded by Alexey Melnikov
2009-03-13
07 Samuel Weiler Request for Last Call review by SECDIR Completed. Reviewer: Larry Zhu.
2009-03-13
07 (System) Removed from agenda for telechat - 2009-03-12
2009-03-08
07 Cullen Jennings State Changes to IESG Evaluation - Defer from Waiting for AD Go-Ahead by Cullen Jennings
2009-03-02
07 Mark Townsley Placed on agenda for telechat - 2009-03-12 by Mark Townsley
2009-02-23
07 (System) State has been changed to Waiting for AD Go-Ahead from In Last Call by system
2009-02-19
07 Samuel Weiler Request for Last Call review by SECDIR is assigned to Larry Zhu
2009-02-19
07 Samuel Weiler Request for Last Call review by SECDIR is assigned to Larry Zhu
2009-02-17
07 Amanda Baber
IANA Last Call comments:

Upon approval of this document, IANA will make the following
assignment under iso.org.dod.internet.mgmt.mib-2 (1.3.6.1.2.1) at
http://www.iana.org/assignments/smi-numbers

Decimal Name Description References
------- …
IANA Last Call comments:

Upon approval of this document, IANA will make the following
assignment under iso.org.dod.internet.mgmt.mib-2 (1.3.6.1.2.1) at
http://www.iana.org/assignments/smi-numbers

Decimal Name Description References
------- | ---- | ----------- | ----------
TBD | ntpSnmp | NTP-SNMP-MIB | [RFC-ntp-ntpv4-mib-05]

We understand the above to be the only IANA Action for this document.
2009-02-09
07 Amy Vezza Last call sent
2009-02-09
07 Amy Vezza State Changes to In Last Call from Last Call Requested by Amy Vezza
2009-02-06
07 Mark Townsley Last Call was requested by Mark Townsley
2009-02-06
07 Mark Townsley State Changes to Last Call Requested from AD Evaluation by Mark Townsley
2009-02-06
07 Mark Townsley [Ballot Position Update] New position, Yes, has been recorded for Mark Townsley
2009-02-06
07 Mark Townsley Ballot has been issued by Mark Townsley
2009-02-06
07 Mark Townsley Created "Approve" ballot
2009-02-06
07 (System) Ballot writeup text was added
2009-02-06
07 (System) Last call text was added
2009-02-06
07 (System) Ballot approval text was added
2008-11-27
07 Mark Townsley State Changes to AD Evaluation from Publication Requested by Mark Townsley
2008-11-20
07 Cindy Morgan
(1.a) Who is the Document Shepherd for this document? Has the Document
Shepherd personally reviewed this version of the document and, in
particular, does he …
(1.a) Who is the Document Shepherd for this document? Has the Document
Shepherd personally reviewed this version of the document and, in
particular, does he or she believe this version is ready for forwarding
to the IESG for publication?

Karen O'Donoghue is the document shepherd. She has reviewed this
version of the document and believes it is ready for the IESG.

(1.b) Has the document had adequate review both from key WG members and
from key non-WG members? Does the Document Shepherd have any concerns
about the depth or breadth of the reviews that have been performed?

Yes, the document has received adequate review and the document shepherd
has no concerns with those reviews.

(1.c) Does the Document Shepherd have concerns that the document needs
more review from a particular or broader perspective, e.g., security,
operational complexity, someone familiar with AAA,
internationalization or XML?

No.

(1.d) Does the Document Shepherd have any specific concerns or issues
with this document that the Responsible Area Director and/or the IESG
should be aware of? For example, perhaps he or she is
uncomfortable with certain parts of the document, or has concerns
whether there really is a need for it. In any event, if the WG has
discussed those issues and has indicated that it still wishes to advance
the document, detail those concerns here. Has an IPR disclosure related
to this document been filed? If so, please include a reference to the
disclosure and summarize the WG discussion and conclusion on this issue.

No.

(1.e) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others being
silent, or does the WG as a whole understand and agree with it?

The document shepherd believes that the WG as a whole supports this
document.

(1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is entered into the ID
Tracker.)

No.

(1.g) Has the Document Shepherd personally verified that the document
satisfies all ID nits? (See
http://www.ietf.org/ID-Checklist.html and
http://tools.ietf.org/tools/idnits/). Boilerplate checks are not
enough; this check needs to be thorough. Has the document met all formal
review criteria it needs to, such as the MIB Doctor, media type and URI
type reviews?

Yes.

(1.h) Has the document split its references into normative and
informative? Are there normative references to documents that are not
ready for advancement or are otherwise in an unclear state? If such
normative references exist, what is the strategy for their completion?
Are there normative references that are downward references, as
described in [RFC3967]? If so, list these downward references to support
the Area Director in the Last Call procedure for them [RFC3967].

The references are split into normative and informative dependencies.
No normative references are outstanding.

(1.i) Has the Document Shepherd verified that the document IANA
consideration section exists and is consistent with the body of the
document? If the document specifies protocol extensions, are
reservations requested in appropriate IANA registries? Are the IANA
registries clearly identified? If
the document creates a new registry, does it define the proposed initial
contents of the registry and an allocation procedure for future
registrations? Does it suggest a reasonable name for the new registry?
See [RFC5226]. If the document describes an Expert Review process has
Shepherd
conferred with the Responsible Area Director so that the IESG can
appoint the needed Expert during the IESG Evaluation?

The IANA Considerations section is consistent and clear.

(1.j) Has the Document Shepherd verified that sections of the document
that are written in a formal language, such as XML code, BNF rules, MIB
definitions, etc., validate correctly in an automated checker?

N/A.

(1.k) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary:

The Network Time Protocol (NTP) is used in networks of all types and
sizes for time synchronization of servers, workstations and other
networked equipment. As time synchronization is more and more a
mission critical service, standardized means for monitoring and
management of this subsystem of a networked host are required to allow
operators of such a service to setup a monitoring system that is
platform- and vendor-independant. This Internet draft provides a
standardized collection of data objects for monitoring the NTP entity of
such a network participant, and it is part of the NTP Version 4
standardization effort.

Working Group Summary:

The NTP working group has done extensive reviews of this document, and
it reflects the consensus of the working group.

Document Quality:

This document has been reviewed by several members of the
ntpwg@lists.ntp.org mailing list and by the NTP WG chairs.
2008-11-20
07 Cindy Morgan Draft Added by Cindy Morgan in state Publication Requested
2008-08-29
05 (System) New version available: draft-ietf-ntp-ntpv4-mib-05.txt
2008-08-28
07 (System) Document has expired
2008-02-25
04 (System) New version available: draft-ietf-ntp-ntpv4-mib-04.txt
2007-12-06
03 (System) New version available: draft-ietf-ntp-ntpv4-mib-03.txt
2007-07-23
02 (System) New version available: draft-ietf-ntp-ntpv4-mib-02.txt
2007-03-07
01 (System) New version available: draft-ietf-ntp-ntpv4-mib-01.txt
2006-06-20
00 (System) New version available: draft-ietf-ntp-ntpv4-mib-00.txt