[ntpwg] My review of: draft-ietf-ntp-ntpv4-mib-05.txt

[Brian Haberman]

Inline...

Bert Wijnen (IETF) wrote:

<snip>

>> - writable objects for which I see no text in the DESCRIPTION clauses
>>  about expected persistency behaviour
> That means you want to know whether an object stores the changes on that
> object permanently or not? I am not sure if this is not
> implementation-specific.
> <bw>
> It SHOULD not be implementation specific.
> How can a management station manage multiple devices (multiple vendors)
> if persistency behaviour of data is unknown? Just trial and error?
> </bw>
>> - Counter32 objects with no test in the DESCRIPTION clauses about
>>  possible discontinuities and which timer object would indicate such.
>>  Specifically, the fact that (I think) 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)
> Not sure what you mean, can you please provide me with an example?
> 
> <bw>
> COuld there be discontinuities when the ntp deamon restarts?
> If so, the management station wants to have a timer-like object to check
> if such things occur. See the definition of Counter32 (RFC2578) and/or check
> other MIB examples
> </bw>

As an example of how the UDP MIB deals with discontinuities, take a look 
at the udpInDatagrams object (and other Counter32 objects) in RFC 4113.

> 
>> - I see a whole list of REVISION clauses. Normally we only have a
>>  single revision clause at RFC publication time. Not a list of revisions
>>  that took place during I-D revisions.
> OK.
>> - I am missing the Copyright statement in the DESCRIPTION clause
>>  of the MODULE_IDENTITY
> I guess this has been overseen but can be added quite easily. Where can
> I find the required copyright statement in its correct form?
> 
> <bw>
> I am not 100% sure what it is at this point in time... there was/is a lot
> of discussion on this on the IETF list at this time. Check with your WG 
> chair(s)
> </bw>

I believe the following is the correct text to include in the 
DESCRIPTION clause:

    Copyright (c) 2009 IETF Trust and the persons identified as the
    document authors.  All rights reserved.

    This document is subject to BCP 78 and the IETF Trust's Legal
    Provisions Relating to IETF Documents
    (http://trustee.ietf.org/license-info) in effect on the date of
    publication of this document.  Please review these documents
    carefully, as they describe your rights and restrictions with respect
    to this document.

<snip>

>> - When I see:
>> 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 }
>>
>>  Then I like to point out that RFC4001 states that the use of InetAddress
>>  SYNTAX, MUST have a DESCRIPTION clause that explain./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 I would do it as follows:
>>
>>    ntpAssocAddressType OBJECT-TYPE
>>       SYNTAX      InetAddressType { ipv4, ipv6 }
>>
>>   ntpAssocAddress OBJECT-TYPE
>>       SYNTAX      InetAddress SIZE(4|16)
>>
> Thanks, I will do it this way because we currently only have NTP over
> IPv4 and IPv6 - to my knowledge.
>> You must check if you also want to use Zoned addressed, because then
>>  that must be added too.
> Any thoughts on that by anybody?

I believe we would need scoped (or zoned) addresses *if* there are 
deployment scenarios where an NTP speaker is associated with multiple 
peers in different limited-scoped networks.  For example, can I have one 
NTP association with node1 via a site-local IPv6 multicast address in a 
VPN connection and another association with node2 via the same 
site-local IPv6 multicast address over a different interface?

If the answer is "yes", then we need to support the scoped (zoned) 
addresses.

Regards,
Brian