Re: [Ntp] Last Call: <draft-ietf-ntp-yang-data-model-10.txt> (A YANG Data Model for NTP) to Proposed Standard

[tom petch <[e-mail]>]

I have two main problems and a lot of lesser ones with this I-D; given
the number, about 50, I am not optimistic that a single cycle of
revision will see them addressed.

I see a potential loophole in the security which I will post separately
since the audience is likely to be different.

References are missing or not specific enough so when I try to compare
values in the I-D with those of the protocol, either I cannot find them
or they seem to be different. Giving values to enumerations is unusual
in YANG, since NETCONF does not transmit them, and their presence
suggests that they are protocol values, in which case I want to see what
the protocol says.  A reference to a 110 page I-D, with two updating
I-D, is inadequate IMO - section numbers are needed in every case.

Introduction
should mention support, or lack thereof, for NMDA

1.4.  Prefixes in Data Node Names
            | ianach    | iana-crypt-hash          | [RFC7317] |
the reference is wrong; this is an IANA- maintained module so the
reference must be to the IANA website

1.5.  Refrences in the Model
/Refrences/References/
/refrenced in /referenced in /

2.  NTP data model

I do not see the value of a condensed model followed immediately by a
full model. Perhaps the full model should be an Appendix although at
less than three pages, this is quite small and would be ok on its own
IMHO.

4.  Relationship with RFC 7317
/supports per-interface configurations /
support per-interface configuration/

5.  Access Rules
/refer access-mode) and attach different acl-rule/
see access-mode) and attach a different acl-rule/

6.  Key Management
/32-bits unsigned /32-bit unsigned/

/this YANG modules/this YANG module/

NTP association (for example unicast-server),
/specefied/specified/

7.  NTP YANG Module

     import iana-crypt-hash {
      reference         "RFC 7317: A YANG Data Model for System
Management";
wrong reference - this module is IANA-maintained so the reference must
be to the IANA website

     contact
        WG List:  <mailto: [e-mail]
this is not the address I see on the datatracker

the I-D has five editors but there are only two here

     typedef access-mode {
I cannot find this in RFC5905

     typedef association-mode {
this I can find but it ranges from 0 to 7 whereas the I-D has 0 to 4 - is
this intended?

     typedef ntp-sync-state {
this I cannot find; a search for 'spike' yields a value of 2 in the
RFC, 5 here - is this intended?

              effect in XXX seconds.";
for what value of XXX?

       leaf packet-sent {
       leaf packet-received {
       leaf packet-dropped {
            discontinuities in the value of sysUpTime.";
those who have been involved with network management for ten years or
less will likely not recognise this object.  You could add a reference
but I suggest you replace it with a YANG-based approach; see for example
how draft-ietf-ospf-yang handles discontinuities

           leaf access-mode {
/defination/definition/

           leaf clock-refid {
...                         reference clock of the peer to
                which clock is synchronized.";

I do not understand this.  Presumably this corresponds to
               type string {
                 length "4";
from the three type union but what object is this?

           leaf clock-offset {
examples could do with units to make it clear that it is '1.232mS' and
not '1.232s'

         leaf address {
           type inet:host;
this includes the domain name, which I see no mention of in the RFC

       list associations {
            /and isconfigured is required/and isconfigured are required/

         leaf address {
           type inet:host;
as above, the description seems to ignore the option of the domain name

         leaf refid {
same union as for leaf clock-refid, but a completely different
description, neither of which I understand.

                '20.1.1.1'
this address would appear to be assigned to Microsoft, not an
affiliation I see among the authors.  Is the company ok with this?

         leaf reach {
           type uint8;
is this the 8-bit p.reach shift register? reference needed (again:-)

         leaf unreach {
ditto

         leaf poll {
           type uint8;
           units "seconds";
           description
             "The polling interval for current association";
is there a useful default?  2s appears in the RFC in places

         leaf offset {
as above, the example values would be clearer with units

         leaf transmit-time {
           type yang:date-and-time;
           description
             "This is the local time, in timestamp format,
              at which the NTP packet departed the peer(T3).
              If the peer becomes unreachable the value is set to zero.";
I think, but am not sure, that a yang:date-and-time can never be set to
zero, the syntax does not allow it; the usual approach with YANG is a
union with another type which can indicate a special condition - int,
boolean, etc

         leaf input-time {
           type yang:date-and-time;
ditto

             leaf ttl {
               type uint8;
               description
                 "Specifies the time to live (TTL)
TTL does not exist in IPv6

             uses common-attributes {
               description
/attribute like/attributes such as/

             leaf ttl {
               type uint8;
               description
                 "Specifies the maximum time to live (TTL) for
TTL does not exist in IPv6

             uses common-attributes {
/attributes like/attributes such as/

             leaf beacon {
what are the units and is there a default? Is there a maximum of 15?  As
ever, a reference could tell me.

8.  Usage Example
lots of examples but none for IPv6 or JSON

8.1
      <sys:ntp xmlns:sys="urn:ietf:params:xml:ns:yang:ietf-ntp">
sys: is a defined prefix and must not be re-used

          <refid>20.1.1.1</refid>
as above, is Microsoft ok with this?

8.2
        <sys:ntp xmlns:sys="urn:ietf:params:xml:ns:yang:ietf-ntp">
sys: is a defined prefix and must not be re-used

8.3
        <sys:ntp xmlns:sys="urn:ietf:params:xml:ns:yang:ietf-ntp">
sys: is a defined prefix and must not be re-used

8.4
        <sys:ntp xmlns:sys="urn:ietf:params:xml:ns:yang:ietf-ntp">
sys: is a defined prefix and must not be re-used

8.5
  "224.1.1.1"
would appear to be a reserved address.  Other RFC used 224.0.1.1

        <sys:ntp xmlns:sys="urn:ietf:params:xml:ns:yang:ietf-ntp">
and again, twice

              <address>224.1.1.1</address>
as above

8.6
  "224.1.1.1"
as above

         <sys:ntp xmlns:sys="urn:ietf:params:xml:ns:yang:ietf-ntp">
as above, twice

8.7
      <ntp xmlns="urn:ietf:params:xml:ns:yang:ietf-ntp">
as above

8.8
      <ntp xmlns="urn:ietf:params:xml:ns:yang:ietf-ntp">
as above

          <refid>20.1.1.1</refid>
as above

8.9
      <ntp xmlns="urn:ietf:params:xml:ns:yang:ietf-ntp">
as above

12.2
    [RFC7317]  Bierman, A. and M. Bjorklund, "A YANG Data Model
wrong reference in the wrong place
this is an IANA-maintained module and so the reference must be to the
IANA website; and since the module is imported, the reference must be
Normative.

Tom Petch


----- Original Message -----
From: "The IESG" <[e-mail]>
To: "IETF-Announce" <[e-mail]>
Cc: <[e-mail]>; <[e-mail]>; <[e-mail]>;
<[e-mail]>; <[e-mail]>
Sent: Friday, January 29, 2021 10:39 PM
Subject: Last Call: <draft-ietf-ntp-yang-data-model-10.txt> (A YANG Data
Model for NTP) to Proposed Standard